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

Há um mês, descompactei a fonte do Linux em uma pasta no Cygwin (eu estava curioso para saber se seria compilado ou não com o MinGW, porque meu outro computador executando o Linux é um Sempron de núcleo único lento). Tentei excluí-lo, mas resta 1 arquivo e ele não será excluído ...

Cygwin reside C:\cygwine eu desarticulei a fonte C:\cygwin\src\linux-3.7.1. Não foi compilado ... Por isso, tentei excluir a pasta. Estava indo bem, até o final, quando percebi que nem todos os arquivos foram excluídos. Tentei excluir a linux-3.7.1pasta novamente e ocorreu um erro:

Eu abri a pasta e descobriu que há um arquivo de origem esquerda: aux.c, que está em C:\cygwin\src\linux-3.7.1\drivers\gpu\drm\nouveau\core\subdev\i2c\aux.c.

Não vai:

• Excluir
• Aberto
• Mover

Propriedades gerais:

Propriedades de segurança:

Como faço para remover este arquivo?

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

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

Os arquivos da lista abaixo tinham significados especiais. Parte disso ainda está presente nas versões modernas do Windows:

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

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

[edit] Testes realizados no win7-x86 ultimate:

Criando um arquivo de teste simples:

S: \> copiar com foo.c
teste
^ Z
        1 arquivo (s) copiado (s).

Verificando o conteúdo:

S: \> digite foo.c
teste

Agora com aux .c

S: \> copiar com aux.c
^ Z
O sistema não pode encontrar o arquivo especificado.
        0 arquivo (s) copiado (s).

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

Nesse caso, obviamente era sobre o significado especial auxherdado dos tempos do DOS , como Hennes apontou corretamente. No entanto, para os leitores que tropeçarem nisso no futuro, gostaria de acrescentar outro caso possível em que esse comportamento possa ser visto.

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

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

1. um programa Win32 que emprega o \\?\X:prefixo dos nomes de caminho para estender o comprimento do caminho disponível de 260 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 enraizado em um subsistema diferente. O antigo subsistema POSIX (mais tarde o Interix agora SUA), o subsistema OS / 2 (antigo, mas existia no NT 3.51) ou alguma camada que não é exatamente um subsistema no sentido do Windows (Cygwin, que eu saiba) criado o arquivo ou pasta. Da mesma forma, o WSL (Windows Subsystem for 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 não Windows.

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

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

Espero que isso ajude a entender um pouco mais os problemas subjacentes. Não queria editar esta resposta longa em uma das outras respostas, embora apenas as complemente. 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 próximo ao máximo absoluto (32767 caracteres) pode ser expandido pelos filtros do gerenciador de objetos e do sistema de arquivos ou pelos próprios sistemas de arquivos (por exemplo, pontos de nova análise) .

Eu tive esse problema e fiquei muito frustrado, nada funcionou. Então, usei um CD do Linux Ubuntu. Inicializado a partir do CD-ROM, foi para o modo de demonstração, acessou onde estavam os arquivos problemáticos e simplesmente os excluiu. Isso funciona como um sonho.