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.
Anzeige
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:
Anzeige
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
Anzeige
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/
Nachtrag: Unter [a] findet noch ein Beitrag, der ein ähnliche Problem beschreibt.
a: http://wordlinks.wordpress.com/2010/10/30/solved-appdatalocalapplicaton-dataapplication-data-repeating-recursion/
Es ist nicht nötig die Dateinamen händisch zu kürzen. Kommandozeile aufmachen und den Befehl:
"rd /s /q [Laufwerksbuchstabe]:\$recycle.bin"
(rd= remove directory; /s = löscht alle Verzeichnisse und Dateien im angegebenen Verzeichnis zusätzlich zu dem Verzeichnis selbst; /q = keine Nachfrage, ob die Verzeichnisbäume mit /s entfernt werden sollen)
eingeben. Damit wird der Recycler gelöscht. Nach Neustart oder Ab- und Anstöpseln der USB-Gerätes wird ein neuer Papierkorb erstellt und das Problem ist gelöst.
Ist zwar etwas spät, aber ich hatte das Problem erst heute und hatte keine Lust alles von Hand zu kürzen. So ist es einfacher und hilft vielleicht Menschen mit ähnlichen Problemen und hochgradiger Faulheit, so wie mir.
ach so: "$recycle.bin" ist der geschütze Systemordner für den Papierkorb. Das ganze funktioniert natürlich auch für alle anderen Ordner. Dazu den entsprechenden Ordner statt das Papierkorbverzeichnis nach dem Backslash eingeben.
mal mit rm -r -f testen :-)
Hallo Günter,
ich hatte eben, bzw. den ganze Tag :-) das gleiche Problem. Eine mit "mklink /j" erzeugte Verzeichnisverbindung kopiert… was zur Rekursion von 350 KB auf 1,88 GB geführt hat bevor ich es gemerkt abgebrochen habe. Ich war schon am verzweifeln weil wirklich nichts geholfen hat. Ich konnte mich nicht mal durchklicken… Directory Opus und Windows Explorer abgestürzt.
Was letztlich geholfen hat, war das banale verschieben des Ordners auf einen USB Stick. Vom Stick lies sich der Ordner dann anstandslos löschen.
ciao, Stefan
Wenn man für Robocopy das Mirroring nutzt, als Quelle einen Leeren Ordner nimmt und als Ziel den Ordner mit zu langen Pfaden. Dann löscht Robocopy auch brav alles ;-))
Hallo,
ich weiß, es ist etwas spät, aber der Fehler ist ein ganz ganz anderer.
Die Verknüpfung "C:\Users\All Users" zeigt auf "C:\ProgramData", sollte aber auf "C:\Users\Public" zeigen.
In "C:\ProgramData" wurde dadurch nämlich eine Verknüpfung von "Anwendungsdaten" auf eben dieses "C:\ProgramData" erzeugt, was für ein prima Rekursionsmittel.
Lösung: Alles, was in "C:\ProgramData" zum öffentlichen Benutzerprofil gehört, in "C:\Users\Public" verschieben, und "C:\Users\All Users" auf "C:\Users\Public" korrigieren.
Einfachste Möglichkeit hierfür ist eine Cygwin Shell. Wer keine Lust auf Cygwin hat, lese hier: https://www.howtogeek.com/howto/16226/complete-guide-to-symbolic-links-symlinks-on-windows-or-linux/
Update: Bitte meinen Kommentar vom 05.03.2018 nicht so glauben. Ich weiß nicht was genau los war, aber ich habe "Öffentlich" und"Gemeinsame Daten" kräftig durcheinander gebracht. Ich hatte Kopfschmerzen und war genervt, das bewirkte wohl einen Zustand geistiger Umnachtung… :-/
Also noch mal ganz in Ruhe:
1) Der symbolische Link von "C:\Users\All Users" auf "C:\ProgramData" ist völlig in Ordnung so!
Hierbei handelt es sich schlicht um alles, was alle User angeht.
2) Der symbolische Link von "C:\ProgramData\Anwendungsdaten" auf "C:\ProgramData" ist ebenfalls in Ordnung so!
Dieser besteht nur, damit "C:\Users\All Users\Anwendungsdaten" auf den richtigen Ordner zeigt.
Normalerweise zeigt der Link "Anwendungsdaten" nämlich auf "AppData\Roaming", aber das gibt es in "All Users" natürlich nicht, man ist quasi schon da.
—
Wo ist nun das Problem?
Das Problem sind Programme, die rekursiv suchen, und nicht mitbekommen, wenn der vermeintliche Unterordner ein Link auf sich selbst ist.
Oder anders ausgedrückt: Das gesuchte Ziel befindet sich in "C:\ProgramData". Immer.