Perché questo file apparentemente non esiste quando si tenta di eliminarlo?

Circa un mese fa, ho rimosso il codice sorgente Linux in una cartella in Cygwin (ero curioso di sapere se sarebbe stato compilato o meno con MinGW perché il mio altro computer con sistema operativo Linux è un lento singolo core di Sempron). Ho provato a eliminarlo, ma rimane un solo file e non verrà eliminato ...

Cygwin risiede in C:\cygwine ho rimosso la fonte in C:\cygwin\src\linux-3.7.1. Non è stato compilato ... Così ho provato a cancellare la cartella. Stava andando bene, fino alla fine, quando ho capito che non tutti i file sono stati cancellati. Ho provato a cancellare linux-3.7.1 di nuovo la cartella e si è verificato un errore:

Ho aperto la cartella e ho scoperto che è rimasto un solo file sorgente: aux.c, il quale è in C:\cygwin\src\linux-3.7.1\drivers\gpu\drm\nouveau\core\subdev\i2c\aux.c.

Non lo farà:

• Elimina
• Aperto
• Mossa

Proprietà generali:

Proprietà di sicurezza:

Come rimuovo questo file?

Prova questo da un prompt dei comandi (elevato):

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

Il problema che hai incontrato è dovuto alle vecchie prenotazioni DOS.

I file nella lista qui sotto avevano un significato speciale. Una parte di questo è ancora presente nelle moderne versioni di Windows:

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

Il modo più semplice per eliminarli è avviare un sistema operativo che non tratti questi nomi di file come speciali. (ad esempio, avviare qualsiasi live CD non Windows).

[modifica] Test eseguiti su win7-x86 definitivo:

Creare un semplice file di test:

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

Controllo del contenuto:

S:\>type foo.c
test

Ora con aux .c

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

Sembra che parti di Windows siano ancora compatibili all'indietro.

In questo caso era ovviamente su significato speciale di aux ereditato dai tempi DOS , come Hennes sottolineato correttamente. Tuttavia, per i lettori che inciampano su questo in futuro vorrei aggiungere un altro caso possibile in cui questo comportamento può essere visto.

Quello è quando un file è stato creato con un punto finale. Ci sono anche altri casi esotici. Ma filename.ext. sarebbe un tale nome di file e non potrebbe normalmente eliminato dal sottosistema Win32. Da qui il trucco Karan entra. S / he usa un nome che prima di passare al livello sottostante il sottosistema Win32 verrà cambiato dal suo \\?\C:\... forma al "nativo" (questo è anche il modo in cui i driver di filtro del file system lo vedono) \??\C:\.... Mentre a seconda della versione di Windows questa può essere una cosiddetta directory di oggetti (usa WinObj di Sysinternals / Microsoft per dare un'occhiata allo spazio dei nomi di object manager) o un link simbolico (da non confondere con l'entità identicamente chiamata in NTFS da Vista) in un'altra directory di oggetti come \DosDevices. Quest'ultimo è solo un nome e descrive la parte dello spazio dei nomi del gestore oggetti visibile per i processi Win32 per impostazione predefinita. Per maggiori dettagli consulta la serie di libri Windows Internals o leggi l'analisi del percorso, in particolare su Project Zero di Google (La guida definitiva su Win32 a NT Path Conversion) . In particolare potresti voler prestare attenzione alla differenza tra Namespace di file Win32 e Namespace del dispositivo Win32 .

Ora come può essere creato un tale file in primo luogo? Ci sono diverse possibilità.

1. un programma Win32 che impiega il \\?\X: prefisso per i nomi dei percorsi per estendere la lunghezza del percorso disponibile da 260 caratteri a circa 32767 caratteri (vedere la nota 1!) creato il file in primo luogo, aggirando così alcuni limitazioni del sottosistema Win32.
2. un programma radicato in un sottosistema diverso. Il precedente sottosistema POSIX (più tardi Interix ora SUA), il sottosistema OS / 2 (già scomparso, ma usato per esistere su NT 3.51) o qualche livello che non è esattamente un sottosistema nel senso di Windows (Cygwin, a mia conoscenza) ha creato il file o la cartella. allo stesso modo WSL (sottosistema di Windows per Linux) su Windows 10 è ora un altro candidato.
3. un sistema operativo diverso lo ha creato (avvio Linux parallelo, per esempio).
4. è un file su una condivisione di rete situata su un server non Windows.

Gli ultimi due punti suggeriscono anche uno dei rimedi citati: avviare un CD live non Windows e rimuovere i file.

Il problema può essere effettivamente confrontato con il caso in cui un vecchio programma Win32 non Unicode viene confrontato con nomi di file da più code page. Spesso non sarà in grado di "trovarne" alcuni, poiché ogni rispettiva codepage ANSI può contenere solo 256 caratteri, mentre UTF-16 (non il suo sottoinsieme UCS-2, tuttavia) può teoricamente codificare una quantità virtualmente illimitata di punti di codice (leggi sull'argomento al unicode.org e Wikipedia ).

Spero che questo aiuti a capire meglio i problemi sottostanti. Non volevo modificare questa lunga risposta in una delle altre risposte, nonostante ciò solo li integra. Le altre risposte sono perfettamente valide senza questo.

Nota 1: la quantità massima di caratteri nel percorso non è assoluta perché un percorso che si avvicina al massimo assoluto (32767 caratteri) può essere espanso sia dal gestore oggetti sia dai filtri del file system o dai file system stessi (ad esempio punti di analisi).

Ho avuto questo problema ed ero molto frustrato, niente ha funzionato. Quindi, ho usato un CD Linux Ubuntu. Avviato da CD-ROM, è andato in modalità demo, ha avuto accesso ai file fastidiosi e li ha semplicemente cancellati. Funziona come un sogno.