Por que esse arquivo aparentemente não existe ao tentar excluí-lo?

Question

Mais ou menos um mês atrás, eu descompactei o código fonte do Linux em uma pasta no Cygwin (eu estava curioso para saber se ele seria ou não compilado com o MinGW porque meu outro computador rodando Linux é um Sempron de um único núcleo lento). Eu tentei excluí-lo, mas resta apenas 1 arquivo e ele não será excluído ...

O Cygwin reside em C:\cygwin e eu descompactei a origem em C:\cygwin\src\linux-3.7.1 . Não compilou ... Então eu tentei deletar a pasta. Estava indo bem, até que no final, percebi que nem todos os arquivos foram deletados. Tentei excluir novamente a pasta linux-3.7.1 e um erro apareceu:

Euabriapastaedescobriqueaindarestaumarquivodeorigem:aux.c,queestáemC:\cygwin\src\linux-3.7.1\drivers\gpu\drm\nouveau\core\subdev\i2c\aux.c.

Nãoserá:

• Excluir
• Abrir
• Mover

Propriedadesgerais:

Propriedades de segurança:

Como removo este arquivo?

    

Answer 1

Tente isso em um prompt de comando (elevado):

del \?\C:\cygwin\src\linux-3.7.1\drivers\gpu\drm\nouveau\core\subdev\i2c\aux.c

    

Answer 2

O problema que você encontrou é devido a antigas reservas do DOS.

Os arquivos na lista abaixo tiveram significados especiais. Parte disso ainda está presente nas versões modernas das janelas:

CON, PRN, AUX , RELÓGIO $, NUL, COM1, COM2, COM3, COM4, COM5, COM6, COM7, COM8, COM9 LPT1, LPT2, LPT3, LPT4, LPT5, LPT6, LPT7, LPT8 e LPT9.

A maneira mais fácil de apagá-los é inicializar um sistema operacional que não trata esses nomes de arquivos como especiais. (por exemplo, inicialize qualquer liveCD que não seja do windows).

[edit] Testes feitos no win7-x86 ultimate:

Criando um arquivo de teste simples:

S:\>copy con foo.c
test
^Z
        1 file(s) copied.

Verificando o conteúdo:

S:\>type foo.c
test

Agora com aux .c

S:\>copy con aux.c
^Z
The system cannot find the file specified.
        0 file(s) copied.

Parece que partes do Windows ainda são compatíveis com versões anteriores.

    

Answer 3

Nesse caso, era obviamente o significado especial de aux herdado do DOS vezes , como Hennes apontou corretamente. No entanto, para os leitores tropeçarem no futuro, gostaria de acrescentar outro possível caso em que esse comportamento pode ser visto.

Foi quando um arquivo foi criado com um ponto final. Existem mais casos exóticos também. Mas filename.ext. seria um nome de arquivo e normalmente não poderia ser excluído do subsistema Win32. É aí que entra o truque de Karan . Ele usa um nome que antes de ser passado para a camada abaixo do Win32 O subsistema será alterado de seu \?\C:\... para o "nativo" (também é assim que os drivers de filtro do sistema de arquivos o veem), forma \??\C:\... . Considerando que dependendo da versão do Windows este pode ser um diretório chamado objeto (use WinObj da Sysinternals / Microsoft para espiar o namespace do gerenciador de objetos) ou um link simbólico (não deve ser confundido com a entidade com nomes idênticos no NTFS desde o Vista) para outro diretório de objetos, como \DosDevices . O último é meramente um nome e descreve a parte do namespace do gerenciador de objetos visível para os processos do Win32 por padrão. Para mais detalhes, confira a série de livros Windows Internals ou leia sobre análise de caminho em particular no Projeto Zero do Google. (O Guia Definitivo em Win32 para NT Path Conversion) . Em particular, você pode querer prestar atenção à diferença entre os Namespaces de Arquivos Win32 e os Namespaces de Dispositivo Win32 .

Agora, como esse arquivo pode ser criado em primeiro lugar? Existem várias possibilidades.

1. um programa Win32 que emprega o prefixo \?\X: para nomes de caminho para estender o comprimento do caminho disponível de 260 caracteres para aproximadamente 32767 caracteres (consulte a nota de rodapé 1!) criou o arquivo em primeiro lugar, contornando algumas limitações do subsistema Win32.
2. um programa baseado em um subsistema diferente. O antigo subsistema POSIX (mais tarde Interix agora SUA), o subsistema OS / 2 (há muito desaparecido, mas existia no NT 3.51) ou alguma camada que não é exatamente um subsistema no sentido do Windows (Cygwin, que eu saiba) criou o arquivo ou pasta. Da mesma forma, o WSL (Windows Subsystem para Linux) no Windows 10 é agora outro candidato.
3. um sistema operacional diferente o criou (inicialização paralela do Linux, por exemplo).
4. é um arquivo em um compartilhamento de rede localizado em um servidor que não seja Windows.

Os dois últimos pontos também sugerem um dos remédios mencionados: inicialize um CD não-Windows e remova o (s) arquivo (s).

O problema pode, na verdade, ser comparado ao caso em que um programa antigo não-Unicode Win32 é confrontado com nomes de arquivos de várias páginas de código. Muitas vezes, ele não será capaz de "encontrar" alguns deles, pois cada página de código ANSI só pode caber 256 caracteres, enquanto UTF-16 (no entanto, não seu subconjunto UCS-2) pode teoricamente codificar uma quantidade virtualmente ilimitada de pontos de código (leia o tópico no unicode.org e Wikipedia ).

Espero que isso ajude a entender um pouco mais os problemas subjacentes. Não queria editar essa resposta longa em uma das outras respostas, embora apenas as complementasse. As outras respostas são perfeitamente válidas sem essa.

Nota de rodapé 1: a quantidade máxima de caracteres no caminho não é absoluta porque um caminho que está próximo do máximo absoluto (32767 caracteres) pode ser expandido tanto pelo gerenciador de objetos quanto pelo sistema de arquivos filtros ou sistemas de arquivos (por exemplo, pontos de nova análise).

    

Answer 4

Eu tive esse problema e fiquei muito frustrado, nada funcionou. Então, eu usei um CD do Ubuntu Linux. Inicializado a partir de CDROM, foi para o modo de demonstração, acessado onde os arquivos problemáticos foram e simplesmente os apagou. Funciona como um sonho.