Sachen gibt’s, die es dürfte es eigentlich gar nicht geben. Weigerte sich Windows 7 doch kürzlich, einen von mir angelegten Ordner Test mit dem (scheinbar leeren) Unterordner Win zu löschen. Es wurde bemängelt, dass der Ordner Quelldateien enthält, deren Pfad zu lang für den Papierkorb sei. Und der Löschversuch endete mit einem Dialogfeld, das mitteilte, dass Dateien wie AdobeESDGlobalApps.xml wegen einer zu langen Pfadangabe nicht löschbar seien. Das Einzige, was angeboten wurde, war das Löschen dieser Dateien zu überspringen. Hat mich dann etwas Aufwand gekostet, diesen Ordner doch noch von der Platte zu putzen.
Werbung
Ein recht bizarres Problem
Das Problem, auf das ich gestoßen bin, ist schon reichlich bizzar. Windows enthält seit NT 4 ein Limit für Pfadangaben von 259 Zeichen (einschließlich des Dateinamens). Ergo können eigentlich nur Ordnerstrukturen bis zu dieser Pfadtiefe erzeugt werden. Dummerweise wollte ich für einige Tests einen Ordner mit ein paar Dateien haben. Und noch dümmer, auf meiner Partition gammelte noch ein Ordner Windows.old aus einer alten Windows-Installation rum, den ich zur Sicherheit behalten habe (um ggf. auf Benutzerdaten oder -Eisntellungen dieser Installtion zugreifen zu können).
Ich also nicht faul, kopiere diesen Ordner in einen neu angelegten Ordner Test und benenne den Unterordner Windows.old in Win um. Eigentlich kein Problem und ich konnte meine Tests mit den Dateien dieses neuen Ordners machen. Als ich allerdings diesen Ordner Test löschen wollte, fiel mir die Kinnlade herunter.
Beim Löschen des Ordners Test samt Unterordnern fragt Windows 7 (HP 32 Bit) nach, ob ich das wirklich möchte, da der Ordner Elemente enthalte, die zu lang für den Papierkorb sind. Hab ich mit Ja bestätigt, da ich das Zeugs ja los werden wollte. Windows löschte auch wie ein Weltmeister, kam dann aber irgendwann verschämt aus der Reserve und brachte in einem Dialogfeld mit dem Titel Quellpfad ist zu lang die Meldung Die Quelldateinamen sind zu lang für das Dateisstem. Verschieben Sie sie an einen anderen Ort… und ich konnte im Dialogfeld nur noch die Überspringen-Schaltfläche wählen. Brrrr – da hat’s mich aber schon geschüttelt. Und nachdem ich mit dem Verschieben des Ordners Win gescheitert bin, habe ich das Ganze mal analysiert.
Ursachenforschung und Lösung
Nachdem ich die Anzeige versteckter Systemdateien im Ordnerfenster eingeschaltet habe, sehe ich, dass im Ordner Win ein Pfad enthalten ist, der in etwa folgendermaßen ausschaut:
C:\Test\Win\Documents and Settings\All Users\Anwendungsdaten\
Anwendungsdaten\Anwendungsdaten\Anwendungsdaten\
Anwendungsdaten\Anwendungsdaten\….
Dort finden sich Dateien wie AdobeESDGlobalApps.xml – die Dateien stammen vom Acrobat Reader 9.0. Der Versuch, das Gelumps mit Dateimanagern wie A43 oder TotalCommander zu löschen (diese setzen nicht auf dem Windows-API auf und A43 kann auch in einer Windows PE-Umgebung verwendete werden) scheiterte ebenfalls wegen zu langem Pfadnamen. Der TotalCommander war wenigstens noch so gnädig, mir mitzuteilen, dass der Ordnerpfad 438 Zeichen umfasse und damit die 259-Zeichenbegrenzung für Pfade in Windows überschreite. Na prima – und was mache ich jetzt?
Löschen in der Eingabeaufforderung und die Idee, mal ein Chkdsk beim nächsten Systemstart auszuführen, brachten kein Ergebnis. Auf den Einsatz weiterer obskurer Tools habe ich dann verzichtet, da diese wohl ebenfalls keinen Erfolg bringen.
Zum Schluss habe ich dann die Ochsentour gestartet und die Unter-Unter- … Unterordner Anwendungsdaten schrittweise in A1 umbenannt und die Teilzweige dann in den Unterordner Test verschoben. Hat zwar eine Weile gedauert, aber irgendwann hatte ich dann den letzten Unterordner Anwendungsdaten im Ordner Test – und da der Pfad jetzt unter 259-Zeichen lang war, ließen sich Unterordner und Dateien löschen. Anschließend konnte auch die Ordnerstruktur gelöscht werden.
Fazit der Ursachenforschung: Absudistan ist überall!
Während meiner Versuche, die garstigen Ordner zu löschen, habe ich natürlich noch einiges an Feldforschung betrieben. Der Originalordner Windows.old enthielt z.B. die obigen Ordnerstruktur nicht, sondern einen NTFS-Link Documents and Settings\All Users\…\Anwendungsdaten\…\Anwendungsdaten\… Normalerweise lassen sich solche NTFS-Links nicht unter Windows anwählen. Durch die Neuinstallation von Windows 7 wurde aber dieser NTFS-Link offenbar in eine Verknüpfung umgewandelt. Und bei meinem Kopiervorgang machte Windows aus dieser Verknüpfung Ordnereinträge im Zielordner Test\Win, versaht diese aber noch mit dem System-Attribut. Nur dadurch war es wohl möglich, dass der 438 Zeichen umfassende Pfad entstehen konnte.
Nachdem ich halbwegs zur Lösung gelangt war, habe ich noch etwas recherchiert. Das "Adobe-Datei-Lösch-Problem" scheint einige Leute geplagt zu haben. Vordergründig kam dort vorher Robocopy zum Kopieren von Dateien und Ordnern zum Einsatz, was wohl diese Probleme auch verursacht. Aber hier bei mir wurde die Windows 7-Kopierfunktion genutzt.
Interessierte Leser seien daher auf den Beitrag [1] bei Magerquark.de verwiesen – wo dieses Problem bereits unter Windows Vista analysiert wurde – bin halt zu spät drauf gestoßen, sonst hätte ich mir einige Stunden Arbeit erspart.
Nachtrag: Bei Recherchen zu Backup-Fehlern bin ich noch auf eine mögliche Ursache für das Entstehen des obigen Pfadlängenfehlers gestoßen [2]: In NTFS sind seit Version 3.0 symbolische Links und Reparse Points möglich. Reparse Points sind Links, die auf andere Ordner verweisen. Befindet sich nur der Link im Ordner, auf den verwiesen wird, ergibt sich bei der Abarbeitung der Ordnerstruktur ein Rekursionsproblem. Wird dieses in der betreffenden Software nicht abgefangen, dürfte es zu den hier skizzierten Effekten kommen.
Naja, Absudistan ist überall, und das war der Punkt, wo mich der Gedanke durchzuckte “hätt ich bloß in jungen Jahren was anständiges gelernt – wären mir viele graue Haare erspart geblieben.”
Weiterführende Links:
1: Request for help – ROBOCOPY-Dummfug unter Windows Vista
2: Hinweise zu Reparse Points
3: Windows-Backup Fehlerdiagnosen
Weitere Infos zu Windows 7 finden sich in meinen Windows 7-Titeln.
(c) by Günter Born www.borncity.de
The source of smart computer books
Schlagworte: Dateien nicht löschbar, Pfad zu lang, Problem, Windows 7
das problem, oder ein problem gleicher art gibt es aber schon seit XP.
Danke für die Rückmeldung. War mir nicht bekannt – und in Win XP wurden NTFS-Links auf Ebene der Benutzeroberfläche auch nicht eingesetzt. Da könnte doch höchstens Robocopy als Ursache auftreten – oder?
Ich hatte beim Löschen einer QT Lib Installation das gleiche Problem. Die Lösung ( sofern man eine findet) ist einfach. Man installiere sich den freien explorer plus plus, gehe in den tiefsten Ordner und lösche. Das Problem besteht in allen NTFS Dateisystemen . Absurd das das Problem immer noch nicht von MS gefixst wurde
Gruss
Gazelli
Danke für die Info. Ich glaube, ich habe so einige Tools ausprobiert, ohne Erfolg.
Eine mögliche Theorie von mir, ist, dass dieser Effekt durch “reparse points” (NTFS-Links) ausgelöst wird, die ggf. eine rekursive Ordnerstruktur erzeugen (und wenn Programme diese Rekusion nicht überwachen, kommen solche Effekte zum Vorschein). Auf diesen Ansatz bin ich bei der Analyse von Backup-Problemen gekommen (siehe Backup-Diagnose).
beim sichern meines Profilordners durch traybackup bin auf auf das gleiche Problem gestoßen. Auch bei mir wurde Win7 neu installiert. Auch habe ich einen alten WinXP-Ordner mit all meinen Daten.
Ich wollte gerade in den letzten “Anwendungsdaten”-Ordner “absteigen”, aber ich habe keinen Zugriff auf den Ordner “Anwendungsdaten”. Möglicherweise liegt das an dieser NTFS-3.0-Ordnerverknüpfung. Aber wi gelange ich dorthin bzw. wie gehe ich das Ganze am besten an?
Hoffe auf Hilfe!
Gruß
Achim
Die Verweigerung des Zugriffs auf Anwendungsdaten liegt daran, dass dies kein Ordner sondern ein NTFS-Link auf Applications Data oder AppData ist (siehe auch [1]). Der “zu lange Pfad” muss also in einem anderen Ordner stecken. Zumindest ergibt sich für mich aus der Ferne dieses Bild.
1: http://www.borncity.com/blog/2007/07/22/ordner-mysterien-in-windows-vista/