Auch wenn es möglich ist, die Pfad-Längenbegrenzung aufzuheben, kann es immer noch dazu kommen, dass Programme oder sogar Windows bei der Abarbeitung von Aufgaben streiken, wenn das Limit überschritten wird.
Seit 2012 gibt es ein kleines portables Tool, mit GUI, für die Kommandozeilen oder als PowerShell-Skript, welches die Länge der einzelnen Pfade von einem ausgewählten Ordner oder einer Datei selber anzeigen kann. In den letzten Wochen ist in die Entwicklung richtig „Bewegung“ gekommen.
- Suchvorgänge können nun abgebrochen werden
- Auswahl die Kopie als CSV in die Zwischenablage zu kopieren
- Drag & Drop eines Ordners in die GUI
- PathLengthCheckerGUI.exe unterstützt jetzt die gleichen Befehlszeilenargumente wie PathLengthChecker.exe, so dass die GUI-Anwendung extern gestartet werden kann und sofort ausgeführt wird.
Wer das kleine Tool also schon genutzt hat, sollte nachschauen, ob schon die aktuelle Version 1.70 vom 25.10.2020 vorhanden ist. Wer den Path Length Checker noch nicht kennt… viel Spaß beim Testen.
Info und Download:
- github.com/PathLengthChecker
- github.com/PathLengthChecker/releases
- github.com/PathLengthChecker/GetPathLengths.ps1
Path Length Checker – Pfade einer Datei mit mehr als 256 Zeichen aufspüren
Wohl war, so das ein oder andere Programm kann das nicht.
Darum verlegt man seine TMP-Verzeichnisse ja auch auf
*:\T, *:\T1, *:\T2, *:\T3, *:\T…, und lässt sie nicht unter ich_bin_ein-superlanger_Benutzername\blablabla\wasweisich anlegen.
Bei 7-Zip kann man zum Beispiel ein eigenes TMP-Verzeichnis vorgeben, das ist tunlichst super kurz. Ich bin ein geschwätziger Archivname, der denselben geschwätzigen Namen als Verzeichnis, samt tief gestaffelter Verzeichnisstruktur und Langnamen enthält, ist jetzt wahrlich nicht so ganz selten.
dto.
Downloadverzeichnisse, *:\dl langt da völlig und alles schön im Rootverzeichnis einer Platte/Partition, etc.
dann wird es beim Entpacken mit Rechtsklick nicht so schnell eng.
Schade, dass das Ding nicht in Archive reinschaut und einem dann mitteilt, was da entpackt rauskommt.
Hier mal der Hinweis, dass es keineswegs möglich ist, die Längenbegrenzung für Pfade einfach mal so über die Registry bzw. über die Gruppenrichtlinien aufzuheben. Denn dieses greift ausschließlich bei Anwendungen, die auf Unicode basieren bzw. ein bestimmtes Script enthalten, welches ich hier leider nicht posten konnte.
Und das ist eben ausgerechnet beim Windows Explorer nicht gegeben, der kann also trotz „Aufhebung“ weiterhin keine langen Pfade bearbeiten. Weiterhin deswegen, weil MS das schon seit so langer Zeit versprochen hatte. Es gab dazu unzählige Eingaben, den Explorer doch bitte endlich dahingehend aufzurüsten. Aber Microsoft bleibt da einfach stur, obwohl sie sagten, dass es definitiv zeitnah kommen würde. Das wird wohl nix mehr werden.
Angeblich soll Q-Dir das können, aber bei mir kann auch dieser keine langen Pfade, zumindest in der portablen Version nicht. Total Commander kann es, aber den muss man halt mögen.
Und mit solchen Shortcuts bzw. als angebundene Laufwerke, wie oben vorgeschlagen, muss man halt auch mögen. Meines ist es jedenfalls nicht. Dieser altmodische Explorer ist eines der größten Mankos in Windows.
Ach übrigens, die in Windows per Default versteckte Explorer App kann lange Pfade!
Doch augerechnet die wird nicht weiterentwickelt und ist ja im derzeitigen Zustand indiskutabel.
Das liegt daran, dass die Explorer App die WinRT API verwendet und hier gibt es kein MAX_PATH.
Als Alternative zu der App gibt es Files: https://github.com/files-community/Files
Danke Dir, DK2000. Glaube, dass ich diese App hier schon mal gesehen habe. Sieht recht brauchbar aus, aber leider noch Beta und wohl auch nur in englischer Version.
Kennst Du ein Desktop Explorer-Progamm, dass definitiv lange Pfade kann? Q-Dir kann’s nämlich nicht und Total Commander gefällt mir nicht besonders.
Das Files-Projekt startete bereits im Februar 2019. Ob es da jemals zum Release kommen wird, ist fraglich.
Lange UNC-Pfade konnte Windows auch schon vor der 1609. Das brauchte man nicht freischalten, zumal NTFS schon immer lange Pfade unterstützt hat. Die Limit über MAX_PATH hat Microsoft nur wegen der Kompatibilität zu DOS eingeführt und bis heute beibehalte und viele Anwendungen halten sich halt dran. Genauso wie nach wie vor parallel 8.3 Namen angeleckt werden, sofern man das nicht deaktiviert.
Erinnere mich jetzt wieder, was damals bei der 1609 – als LongPathsEnabled eingeführt wurde – das Argument von Microsoft war, den Explorer noch nicht anzupassen. Ich zitiere mal:
„Es sollte die Änderung jedoch mit Bedacht vorgenommen werden, denn eine Reihe von Applikationen dürfte im Code verschiedene Mechanismen aufweisen, die einen Umgang mit langen Verzeichnis-Namen noch zum Problem werden lassen. Diese Software benötigt dann jeweils ein Update. Hier bleibt dann zumindest zu hoffen, dass die Entwickler die Neuerung nicht aus irgendeinem Grund ignorieren und spätestens bis zu Redstone 1 entsprechende Anpassungen vornehmen.“