¿Por qué aparentemente este archivo no existe cuando intento eliminarlo?

Hace aproximadamente un mes, desmarqué la fuente de Linux en una carpeta en Cygwin (tenía curiosidad de saber si se compilaría con MinGW o no porque mi otra computadora que ejecuta Linux es un Sempron de un solo núcleo lento). Intenté eliminarlo, pero queda 1 archivo y no se eliminará ...

Cygwin reside C:\cygwiny yo desmarqué la fuente C:\cygwin\src\linux-3.7.1. No se compiló ... Así que intenté eliminar la carpeta. Iba bien, hasta el final, cuando me di cuenta de que no se borran todos los archivos. Intenté eliminar la linux-3.7.1carpeta nuevamente, y apareció un error:

Abrí la carpeta y descubrí que queda 1 archivo fuente: aux.cque está en C:\cygwin\src\linux-3.7.1\drivers\gpu\drm\nouveau\core\subdev\i2c\aux.c.

No lo hará:

• Eliminar
• Abierto
• Moverse

Propiedades generales:

Propiedades de seguridad:

¿Cómo elimino este archivo?

Pruebe esto desde un símbolo del sistema (elevado):

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

El problema con el que se encontró se debe a las antiguas reservas de DOS.

Los archivos en la lista a continuación tenían significados especiales. Parte de eso todavía está presente en las versiones modernas de Windows:

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

La forma más fácil de eliminarlos es iniciar un sistema operativo que no trate estos nombres de archivo como especiales. (p. ej., arranque cualquier liveCD que no sea Windows).

[editar] Pruebas realizadas en win7-x86 ultimate:

Crear un archivo de prueba simple:

S: \> copy con foo.c
prueba
^ Z
        1 archivo (s) copiado (s)

Comprobación de los contenidos:

S: \> tipo foo.c
prueba

Ahora con aux .c

S: \> copy con aux.c
^ Z
El sistema no puede encontrar el archivo especificado.
        0 archivos copiados.

Parece que partes de Windows todavía es compatible con versiones anteriores.

En este caso, obviamente se trataba del significado especial de auxheredado de los tiempos de DOS , como Hennes señaló correctamente. Sin embargo, para los lectores que se encuentren con esto en el futuro, me gustaría agregar otro posible caso en el que se pueda ver este comportamiento.

Fue entonces cuando se creó un archivo con un punto final. También hay casos más exóticos. Pero filename.ext.sería un nombre de archivo así y normalmente no podría eliminarse del subsistema Win32. Aquí es donde entra el truco de Karan . Utiliza un nombre que antes de pasar a la capa debajo del subsistema Win32 se cambiará de su \\?\C:\...forma a la "nativa" (así es como lo ven los controladores de filtro del sistema de archivos) formar \??\C:\.... Mientras que, dependiendo de la versión de Windows, este puede ser un llamado directorio de objetos (use WinObj de Sysinternals / Microsoft para mirar dentro del espacio de nombres del administrador de objetos) o un enlace simbólico (que no debe confundirse con la entidad identificada en NTFS desde Vista) a otro directorio de objetos como\DosDevices. Este último es simplemente un nombre y describe la parte del espacio de nombres del administrador de objetos visible para los procesos de Win32 de forma predeterminada. Para obtener más detalles, consulte la serie de libros Windows Internals o lea sobre el análisis de rutas en particular en el Proyecto Cero de Google (La Guía definitiva sobre la conversión de rutas de Win32 a NT) . En particular, es posible que desee prestar atención a la diferencia entre espacios de nombres de archivos Win32 y espacios de nombres de dispositivos Win32 .

Ahora, ¿cómo se puede crear tal archivo en primer lugar? Hay varias posibilidades

1. un programa Win32 que emplea el \\?\X:prefijo para nombres de ruta con el fin de extender la longitud de ruta disponible de 260 caracteres a aproximadamente 32767 caracteres (¡vea la nota al pie 1!) creó el archivo en primer lugar, evitando así algunas limitaciones del subsistema Win32.
2. un programa enraizado en un subsistema diferente. El antiguo subsistema POSIX (más tarde Interix ahora SUA), el subsistema OS / 2 (desaparecido hace tiempo, pero solía existir en NT 3.51) o alguna capa que no es exactamente un subsistema en el sentido de Windows (Cygwin, que yo sepa) creado el archivo o carpeta De manera similar, WSL (Windows Subsystem for Linux) en Windows 10 es ahora otro candidato.
3. lo creó un sistema operativo diferente (arranque paralelo de Linux, por ejemplo).
4. Es un archivo en un recurso compartido de red ubicado en un servidor que no es Windows.

Los dos últimos puntos también sugieren una de las soluciones mencionadas: inicie un CD en vivo que no sea Windows y elimine los archivos.

El problema puede compararse realmente con el caso en el que un antiguo programa Win32 no Unicode se enfrenta a nombres de archivos de múltiples páginas de códigos. A menudo no podrá "encontrar" algunos de ellos, porque cada página de códigos ANSI respectiva solo puede caber 256 caracteres, mientras que UTF-16 (no su subconjunto UCS-2, sin embargo) puede codificar teóricamente una cantidad virtualmente ilimitada de puntos de código (lea sobre el tema en unicode.org y Wikipedia ).

Espero que esto ayude a comprender los problemas subyacentes un poco más. No quería editar esta respuesta larga en una de las otras respuestas, aunque solo las complementa. Las otras respuestas son perfectamente válidas sin esta.

Nota 1: la cantidad máxima de caracteres en la ruta no es absoluta porque una ruta que está cerca del máximo absoluto (32767 caracteres) bien puede expandirse tanto por el administrador de objetos como por los filtros del sistema de archivos o los propios sistemas de archivos (por ejemplo, puntos de análisis) .

Tuve este problema y estaba muy frustrado, nada funcionó. Luego, utilicé un CD de Linux Ubuntu. Arrancado desde CDROM, fue al modo de demostración, accedió a donde estaban los archivos problemáticos y simplemente los eliminó. Funciona como un sueño.