Warum existiert diese Datei anscheinend nicht, wenn versucht wird, sie zu löschen?

Vor ungefähr einem Monat habe ich die Linux-Quelle in einem Ordner in Cygwin entkernt (ich war gespannt, ob sie mit MinGW kompiliert werden würde oder nicht, da mein anderer Computer unter Linux ein langsames Single-Core-Sempron ist). Ich habe versucht, es zu löschen, aber es ist noch 1 Datei übrig, und es wird nicht gelöscht ...

Cygwin wohnt in C:\cygwinund ich habe die Quelle in entkernt C:\cygwin\src\linux-3.7.1. Es wurde nicht kompiliert ... Also habe ich versucht, den Ordner zu löschen. Es lief gut, bis ich am Ende feststellte, dass nicht alle Dateien gelöscht wurden. Ich habe erneut versucht, den linux-3.7.1Ordner zu löschen , und es ist ein Fehler aufgetreten:

Ich habe den Ordner geöffnet und festgestellt, dass noch 1 Quelldatei übrig ist : aux.c, die sich in befindet C:\cygwin\src\linux-3.7.1\drivers\gpu\drm\nouveau\core\subdev\i2c\aux.c.

Es wird nicht:

• Löschen
• Öffnen
• Bewegung

Allgemeine Eigenschaften:

Sicherheitseigenschaften:

Wie entferne ich diese Datei?

Versuchen Sie dies an einer (erhöhten) Eingabeaufforderung:

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

Das Problem, auf das Sie gestoßen sind, ist auf alte DOS-Vorbehalte zurückzuführen.

Dateien in der folgenden Liste hatten besondere Bedeutungen. Ein Teil davon ist in modernen Windows-Versionen noch vorhanden:

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

Der einfachste Weg, sie zu löschen, besteht darin, ein Betriebssystem zu starten, das diese Dateinamen nicht als speziell behandelt. (z. B. eine Nicht-Windows-Live-CD booten).

[Bearbeiten] Tests unter win7-x86 Ultimate:

Erstellen einer einfachen Testdatei:

S: \> copy con foo.c
Prüfung
^ Z.
        1 Datei (en) kopiert.

Überprüfen des Inhalts:

S: \> Geben Sie foo.c ein
Prüfung

Jetzt mit aux .c

S: \> copy con aux.c
^ Z.
Die angegebene Datei wurde vom System nicht gefunden.
        0 Datei (en) kopiert.

Es scheint, dass Teile von Fenstern immer noch abwärtskompatibel sind.

In diesem Fall ging es offensichtlich um die besondere Bedeutung von auxaus DOS-Zeiten geerbt , wie Hennes richtig hervorhob. Für die Leser, die in Zukunft darüber stolpern, möchte ich jedoch einen weiteren möglichen Fall hinzufügen, in dem dieses Verhalten sichtbar wird.

Zu diesem Zeitpunkt wurde eine Datei mit einem nachgestellten Punkt erstellt. Es gibt auch exotischere Fälle. Wäre filename.ext.aber ein solcher Dateiname und könnte normalerweise nicht aus dem Win32-Subsystem gelöscht werden. Hier kommt der Trick von Karan ins Spiel. Er verwendet einen Namen, der vor der Übergabe an die Ebene unter dem Win32-Subsystem von seiner \\?\C:\...Form in die "native" geändert wird (so sehen es auch die Filtersystem-Filtertreiber). Form \??\C:\.... Je nach Windows-Version kann dies ein sogenanntes Objektverzeichnis sein (verwenden Sie WinObj von Sysinternals / Microsoft, um einen Blick in den Objektmanager-Namespace zu werfen) oder ein symbolischer Link (nicht zu verwechseln mit der identisch benannten Entität in NTFS seit Vista). in ein anderes Objektverzeichnis wie\DosDevices. Letzteres ist nur ein Name und beschreibt den Teil des Objektmanager-Namespace, der standardmäßig für Win32-Prozesse sichtbar ist. Weitere Informationen finden Sie in der Buchreihe Windows Internals oder in der Pfadanalyse von Google, insbesondere in Googles Project Zero (The Definitive Guide on Win32 to NT Path Conversion) . Insbesondere möchten Sie möglicherweise auf den Unterschied zwischen Win32-Dateinamensräumen und Win32-Gerätenamensräumen achten .

Wie kann nun überhaupt eine solche Datei erstellt werden? Es gibt mehrere Möglichkeiten.

1. Ein Win32-Programm, das das \\?\X:Präfix für Pfadnamen verwendet, um die verfügbare Pfadlänge von 260 Zeichen auf ungefähr 32767 Zeichen (siehe Fußnote 1!) zu erweitern, hat die Datei zuerst erstellt und damit einige Einschränkungen des Win32-Subsystems umgangen .
2. Ein Programm, das in einem anderen Subsystem verwurzelt ist. Das frühere POSIX-Subsystem (später Interix jetzt SUA), das OS / 2-Subsystem (längst weg, aber früher unter NT 3.51 vorhanden) oder eine Schicht, die meines Wissens nicht genau ein Subsystem im Windows-Sinne ist (Cygwin, erstellt) die Datei oder den Ordner. Ebenso ist WSL (Windows Subsystem für Linux) unter Windows 10 ein weiterer Kandidat.
3. Es wurde von einem anderen Betriebssystem erstellt (z. B. paralleler Linux-Start).
4. Es handelt sich um eine Datei auf einer Netzwerkfreigabe, die sich auf einem Nicht-Windows-Server befindet.

Die letzten beiden Punkte weisen auch auf eines der genannten Mittel hin: Starten Sie eine Nicht-Windows-Live-CD und entfernen Sie die Datei (en).

Das Problem kann tatsächlich mit dem Fall verglichen werden, in dem ein altes Nicht-Unicode-Win32-Programm mit Dateinamen von mehreren Codepages konfrontiert wird. Oft werden einige von ihnen nicht "gefunden", da die jeweilige ANSI-Codepage nur 256 Zeichen enthalten kann, während UTF-16 (jedoch nicht die Teilmenge UCS-2) theoretisch eine praktisch unbegrenzte Anzahl von Codepunkten codieren kann (Lesen Sie das Thema unter unicode.org und Wikipedia nach ).

Ich hoffe, dies hilft, die zugrunde liegenden Probleme ein bisschen besser zu verstehen. Ich wollte diese lange Antwort nicht in eine der anderen Antworten umwandeln, obwohl sie sie nur ergänzt. Die anderen Antworten sind ohne diese vollkommen gültig.

Fußnote 1: Die maximale Anzahl von Zeichen im Pfad ist nicht absolut, da ein Pfad, der nahe am absoluten Maximum liegt (32767 Zeichen), sowohl vom Objektmanager als auch von Dateisystemfiltern oder Dateisystemen selbst erweitert werden kann (z. B. Analysepunkte). .

Ich hatte dieses Problem und war sehr frustriert, nichts hat funktioniert. Dann habe ich eine Linux Ubuntu CD verwendet. Von der CD-ROM gestartet, in den Demo-Modus gewechselt, auf die problematischen Dateien zugegriffen und sie einfach gelöscht. Es funktioniert wie ein Traum.