Zu langen Pfad löschen

[Gast]

Hallo,

aus irgendeinem Grund (ich vermute mal, SmartCVS hatte einen Bug) ein Pfadstruktur, welche länger ist als die von Windows unterstützen 260 Zeichen.

Das sieht bei mir so aus:

C:\Dokumente und Einstellungen\xxx\Desktop\cdt\all\org.eclipse.cdt.core\org.eclipse.cdt.core\org. eclipse.cdt.core\org.eclipse.cdt.core\org.eclipse.cdt.core\org.eclipse.cdt.core\ org.eclipse.cdt.core\org.eclipse.cdt.core\org.eclipse.cdt.core\org.eclipse.cdt.c ore\ usw.

Ab einer bestimmten Pfadlänge macht der Explorer nicht mehr mit. Löschen per Explorer meint auch Pfad zu lang. rd /s geht auch nicht.

Wie kriege ich diese Ordner weg?

[eViLsTieFel]

Da hilft nur noch der Windows-eigene SUBST Befehl

SUBST [Laufwerk1: [Laufwerk2:]Pfad]
SUBST Laufwerk1: /D

Laufwerk1: Laufwerkbezeichnung, die dem Pfad zugewiesen werden soll.
[Laufwerk2:]Pfad Laufwerk und Pfad, die durch Laufwerk1: angesprochen
werden sollen.
/D Hebt die Zuordnung für das (virtuelle) Laufwerk1 wieder auf.

SUBST ohne Parameter zeigt die mit SUBST erstellten, virtuellen Laufwerke an.

Damit kannst du einem Ordner einen virtuellen Laufwerksbuchstaben zuordnen und dann dort den relativ kürzeren restlichen Pfad löschen. Danach einfach das Mapping wieder entfernen und gegessen ist die Suppe.

[nn23]

Das wird nen Fehler in der Zuordnungstabelle der Partition sein.
Mach mal nen Checkdisk, der sollte das beheben.

[eViLsTieFel]

Es gibt tatsächlich eine Limitierung, ob das mit Fehlern in der Zuordnungstabelle verbunden ist, weiß ich allerdings nicht. Ich hatte das Problem, wenn ich in einer schon relativ weit verschachtelten Ordnerstruktur zum Beispiel Archive entpacken wollte, die noch eine tiefere Struktur beinhalten und dazu noch lange Dateinamen. Der Fehler ist also reproduzierbar, lässt sich aber über die oben genannte Methode einwandfrei beheben.

Warum das allerdings auftritt, ist mir auch nicht ganz klar, denn eigentlich sollte es mit NTFS solche Einschränkungen doch nicht mehr geben. Aus den 8-Zeichen pro Dateinamen sind wir doch schon lange herausgewachsen :confused:

[Lokadamus]

Warum das allerdings auftritt, ist mir auch nicht ganz klar, denn eigentlich sollte es mit NTFS solche Einschränkungen doch nicht mehr geben. Aus den 8-Zeichen pro Dateinamen sind wir doch schon lange herausgewachsen :confused:mmm...

Ich sehe gerade bei dem Artikel von Wikipedia, dass du recht haben müsstest. Meine praktische Erfahrung sagt mir aber, dass Windows gerne Probs hat, sobald die Anzahl der Zeichen über 256 geht, egal, ob am Ende ein weiteres Verzeichnis oder eine Datei kommt.
http://de.wikipedia.org/wiki/NTFS#Vorteile_ab_NTFS_1.X_.28gegen.C3.BCber_FAT.29

Was bei mir geholfen hat, war ein paar der Ordner, die dazwischen sind, umzubennen in kurze Version mit nur einem Buchstaben. Dadurch konnte die Länge des Pfades unter 256 gebracht werden und der lange Pfad gelöscht werden.
Alternativ kann man noch versuchen den Pfad zu verschieben.

[nn23]

Ja, XP hat Probs mit langen Dateinamen, aber schaut euch doch mal den Pfad an, den erstellt doch kein normales Programm.
Da ist auf jeden Fall was in der Zuordnungstabelle kaputt, und linkt immer auf sich selbst.

[Sephiroth]

Es gibt tatsächlich eine Limitierung, ob das mit Fehlern in der Zuordnungstabelle verbunden ist, weiß ich allerdings nicht. Ich hatte das Problem, wenn ich in einer schon relativ weit verschachtelten Ordnerstruktur zum Beispiel Archive entpacken wollte, die noch eine tiefere Struktur beinhalten und dazu noch lange Dateinamen. Der Fehler ist also reproduzierbar, lässt sich aber über die oben genannte Methode einwandfrei beheben.

Warum das allerdings auftritt, ist mir auch nicht ganz klar, denn eigentlich sollte es mit NTFS solche Einschränkungen doch nicht mehr geben. Aus den 8-Zeichen pro Dateinamen sind wir doch schon lange herausgewachsen :confused:
Das kommt darauf an wie das Programm den Pfad verwendet/anspricht/zusammensetzt. Bei UNC-Pfaden gibt es deutlich größeres Limit von 32758 Zeichen.

Maximum Path Length

In the Windows API (with some exceptions discussed in the following paragraphs), the maximum length for a path is MAX_PATH, which is defined as 260 characters. A local path is structured in the following order: drive letter, colon, backslash, components separated by backslashes, and a terminating null character. For example, the maximum path on drive D is "D:\<some 256 character path string><NUL>" where "<NUL>" represents the invisible terminating null character for the current system codepage. (The characters < > are used here for visual clarity and cannot be part of a valid path string.)

Note File I/O functions in the Windows API convert "/" to "\" as part of converting the name to an NT-style name, except when using the "\\?\" prefix as detailed in the following sections.

The Windows API has many functions that also have Unicode versions to permit an extended-length path for a maximum total path length of approximately 32,000 characters. This type of path is composed of components separated by backslashes, each up to 255 characters in length. To specify an extended-length path, use the "\\?\" prefix. For example, "\\?\D:\<very long path>". (The characters < > are used here for visual clarity and cannot be part of a valid path string.)

Note The maximum path of 32,000 characters is approximate, because the "\\?\" prefix may be expanded by the system at run time to a longer string, and this expansion applies to the total length.

To specify such a path using UNC, use the "\\?\UNC\" prefix. For example, "\\?\UNC\server\share". These prefixes are not used as part of the path itself. They indicate that the path should be passed to the system with minimal modification, which means that you cannot use forward slashes to represent path separators, or a period to represent the current directory. Also, you cannot use the "\\?\" prefix with a relative path, therefore relative paths are limited to MAX_PATH characters.

When using an API to create a directory, the specified path cannot be so long that you cannot append an 8.3 file name (that is, the directory name cannot exceed MAX_PATH minus 12).

zum Nachlesen: Naming a File or Directory (http://msdn.microsoft.com/en-us/library/aa365247.aspx)