Windows 10: Mit dem Anniversary Update kommen lange Pfad-Namen

Mit dem Anniversary Update - oder eben Windows 10 Redstone - führt Microsoft eine kleine Änderung ein, die letztlich mit einem über viele Jahre vorhandenen Paradigma bricht: Zukünftig kann die Bezeichnung von Pfaden das bisherige Limit von ... mehr... Redstone, Windows 10 Redstone, Anniversary Update, Windows 10 Anniversary Update Bildquelle: Microsoft Redstone, Windows 10 Redstone, Anniversary Update, Windows 10 Anniversary Update Redstone, Windows 10 Redstone, Anniversary Update, Windows 10 Anniversary Update Microsoft

Diese Nachricht vollständig anzeigen.

Jetzt einen Kommentar schreiben
 
Cool dann gibts hoffentlich endlich keine Fehlermeldung mehr wenn ich was aus Ordner X nach Ordner Y kopiere und der Pfad dann zu lang wird und er mich an meckert das er es nicht Kopieren kann eben weil der Pfad zu lang wird. Welch ein Segen!
 
@Eagle02: Jap, ist mir neulich erst passiert, als ich die Beispielprojekte von MS zu den UWP Apps entpackt habe und später weil es eine neue Version gab, diese löschen wollte, ging es nicht...
 
@L_M_A_O: Als eine mögliche Lösung kannst du die Daten auf nen USB Stick verschieben und den Stick weg werfen.
 
@Nebulus Jones: Cool, funktioniert das auch mit SSDs?:D
 
@L_M_A_O: Sollte auch klappen! xD
 
@L_M_A_O: Ich hatte so ein Problem auch letztens. Mal mit Pfaden, mal mit Dateinaben mit denen Windows nicht umgehen konnte. Was da geholfen hat:
Mit einem Packer, bei mir Winrar, das Verzeichnis packen mit der Option "Dateien nach dem Packen löschen".
Alels andere hat versagt. Konsole, alternative Explorer usw. Es kam durch Entpacken drauf und wurde mit dem Packen wieder gelöscht.
 
@Eagle02: Kommt Grade bei Sourcecode immer wieder vor das die Pfade zu lang werden. Wir sagen unseren Leuten immer das sie sich einen Source Ordner direkt im Laufwerksroot anlegen sollen und nicht im eigenen Documents Ordner, der pfad dahin ist eh schon recht lang.
Was das kopieren angeht da helfen aktuell Tools wie Total Commander, der kann jetzt schon mit langen Namen umgehen, denn das darunterliegende NTFS kann das schon ewig, nur der Windows Explorer und einige alte APIs haben das Problem.
 
@cathal: Echt? Mit dem TC hab ich das Problem aber auch, wenn ich bspw. Projektordner löschen will, die npm-Module mit tiefen Abhängigkeitshierarchien beinhalten. Die lassen sich nicht löschen, bis ich die entsprechenden Ordnernamen nacheinander jeweils auf ein Zeichen reduziere.
 
@psylence: Ich kann mich immer daran erinnern beim Kopieren eine Meldung bekommen zu haben, das der Pfad länger ist und es mit anderen Programmen ggf. zu Problemen kommen kann.
Beim löschen könnte ich mir vorstellen, das es mit der Löschmethode zusammenhängt (Papierkorb usw.)
 
@psylence: Man kann das konfigurieren.
Unter Optionen -> Kopieren/Löschen solltest du Standard-Kopiermethode benutzen aktivieren und weiter unten in dem Dialog darf man nicht "Benutze Explorer-Löschmethode" wählen.
ansonsten sollte es eine aktuelle Version sein 8.x sollte reichen denke ich, ich verwende 8.52a 64Bit.
Beim kopieren bekommst du dann einen Dialog ob die überlangen Namen beibehalten werden sollen, löschen klappt einfach so.
 
@Eagle02: für so etwas benutze ich dann momentan robocopy. Auch von Microsoft. Da geht es soweit ich weiß.
 
Das Ganze ist auch per Group Policy Setting möglich. Wird vermutlich das identische Ergebnis sein, wie beim Setzen per Registry.
 
@Mister-X: Die Group Policy ist doch eh nur ein overlay fuer die korrekten Registry keys mit ein wenig Info darueber.
 
@-adrian-: für den nicht-poweruser ist das aber in den meisten fällen die übersichtlichere variante. außerdem kann man innerhalb von firmandomains gpos deutlich einfacher handhaben, als registry werte.
 
@Mister-X: War nur ein hinweis darauf dass die GPO in der tTat genau das gleiche machen wuerde wie die Registry setzen
 
Mal eine Frage:
Wieso schafft Microsoft es nicht, das Windows ab und an die Registry von selbst aufräumt und unnütze einträge löscht?!
Das ist ja u.a. ein Grund, weshalb Windows nach einer gewissen Zeit lahmt oder es zu Komplikationen kommen kann?!
 
@Edelasos: Weil man es bei vielen Einträgen nicht wissen kann, ob diese unnütz sind. Jeder der sein System mit CCleaner mal zerschossen hat, kann dir ein Lied davon singen
 
@mlodin84: Mit dem CCleaner an sich wird das sicher so schnell niemanden passieren, sofern man die Einstellungen lässt, wie sie sind. Dafür ist der CC zu sehr auf Sicherheit ausgelegt und lässt eher Müll drin, bevor er wichtiges aus versehen löscht.
Bei vielen anderen Tools gebe ich dir allerdings Recht.
 
@Edelasos: Bereinigen der Reg bringt an Geschwindigkeit überhaupt nichts.. Das ist ein Mythos der von Tools wie TuneUp und Co verbreitet wird ;) Zu Komplikationen kann es auch nur führen, wenn jemand dran rum schraubt, der keine Ahnung hat, oder Programme schlecht programmiert sind. Da kann in beiden Fällen aber Windows/Microsoft nichts dafür
 
@TheUntouchable: Das ist kein Mythos. Allerdings sind die Zeiten, in denen man das wirklich merken kann, bei den schnellen modernen Rechnern vorbei.
Als die Registry eingeführt wurde und auch noch unter XP (zumindest in den Anfangszeiten), konnte man durch das aufräumen noch spürbar Geschwindigkeit heraus holen, vor allem beim Booten.
Heute lässt sich der Unterschied maximal in Millisekunden messen, spüren kann man hier wirklich nichts mehr.
Ein Mythos ist es aber definitiv nicht.
 
@Scaver: Um diesen Thema nochmal aufzugreifen: Da muss ich dich leider enttäuschen, denn genau seit Windows XP wird nicht mehr die komplette Registry eingelesen, wie es bei den Systemen davor war, sondern nur noch die Dinge, die gebraucht werden. Daher bringt es nichts, die Registry zu säubern oder sonstige Dinge zu tun :) Daher ist dieses Thema eben schon ein Mythos, jedenfalls bei allen System ab XP ;)
Hier noch ein kleiner Artikel dazu: http://wantastisch.de/registry-cleaner-und-andere-wunderheiler/
 
@Edelasos: lol, Du fragst nicht ernsthaft, warum es eine Firma, die bis jetzt gebraucht hat, Pfadlängen von über 260 Zeichen zu implementieren, nicht schafft, dass die Registry in regelmäßigen Abständen entschlackt wird... ;-)

Aber hier kannst Du zumindest beruhigt sein. Die Anzahl der Einträge in der Registry hat KEINEN Einfluss auf die Geschwindigkeit des Systems (mehrmals von Mark Russinovich bestätigt).
 
@doubledown: Nicht keinen. Nur keinen Messbaren. Wenn bei einer "maximal Schlanken" Registry 1 Mio zugriffen zusammen 1 Sekunde ebrauchen, sind bei es einer über 10 Jahre aufgeblähten halt 1,001 Sekunden.

Beim Einsatz von SSDs gehts dann von 0,5 Sekunden auf 0,50001.
 
@Bautz: Das dann aber eben auch nur bei moderner Technik. Zur Zeit als die Registry kam, war das etwas anderes. Da konnte man durch nen dutzend Einträge schon ein paar Sekunden beim booten raus holen. Und das dauerte zu Windows 95 Zeiten definitiv lang genug.
 
@Scaver: Ja, da waren es bestimmt 1,01 Sekunden. Ich arbeite und spiele nun seit 20 Jahren mit Rechnern (Lebenszeit mind 2, meist eher 3 Jahre). Ich musste bisher nur ein einziges mal neu aufsetzen).
 
@Edelasos: Diesen Mythos hat die C't vor Jahren schon besprochen.
Meine Rechner sind nach Jahren mit dem selben Windows noch genauso schnell wie am ersten Tag.

Was soll etwas in der Registry stören das eh nicht genutzt wird? Wird dein Rechner auch langsamer weil auf deiner Festplatte 1000 Bilder mehr liegen die du sowieso nie anschaust?
 
@Paradise: die Registry wird beim Start komplett in den RAM geladen. Daher hat es minimale Auswirkungen auf die Bootzeit und den RAM Verbrauch.
 
@Paradise: Bitte nicht vergessen, dass die Registry eine Datei ist, die VOLLSTÄNDIG beim booten geladen werden muss. Ob diese nun 10 Tausend oder 1 Millionen Einträge hat, macht da einen Unterschied. dieser ist, bei heutiger Technik, zwar nicht mehr spürbar, aber vorhanden und Messbar und zwar im Millisekunden Bereich. Aber auch der Bruchteil einer Sekunde länger ist nicht mehr gleich schnell!
Gerade im IT Bereich kann man NICHT sagen "ein paar Millisekunden zählen nicht!".
Zu Zeiten von Win95 z.B. haben ein Dutzend Einträge schon einige Sekunden (locker bis zu 20 Sekunden) beim booten ausgemacht!

Ach ja und bzgl. der Bilder... ja, bei alten HDDs (mechanische) ist das so. Aber selbst bei den aktuellen merkst Du das nicht mehr, kannst es nur messen. Bei denen zu Win 95 Zeiten machte das aber auch einige wenige Sekunden aus (meist ca. 1-2 Sekunden).
Bei SSDs hingegen hast Du Recht, da macht es keinen Unterschied mehr, aber nur da!
 
@Scaver: So so meine 4 TB Platte die nur noch 200GB Platz hat ist also langsamer wie die die noch 2TB frei hat.
 
@Edelasos: Die Registry ist eine hierarchische Datenbank. Hierarchien die gar nicht durchsucht werden fallen bei der Suche nach einem Eintrag nur zum Teil auf. Eine Verlansamung tritt in messbaren aber nicht spürbaren Umfang auf (siehe Post von @Bautz).

Wenn man einen Baum durchsucht, dann fallen an jedem Zweig immer eine große Anzahl Einträge weg. Das ist der Grund wieso es kaum juckt. Wenn du einige millionen Dateien im Dateisystem hast wird auch nicht das ganze Dateisystem langsamer, oder? Das Dateisystem wird erst (aber auch nur an dieser Stelle!) langsamer wenn du hunderttausende Einträge an *einem* Zweig hast (also in einem Ordner sehr viele Dateien)
 
@sinni800: Mit der Registry hast Du Recht, bei dem Dateisystem aber nicht, zumindest nicht auf mechanischen HDDs!
 
@Scaver: Die NTFS Dateisystemdatenbank ist ein B-Tree (ein "Binärer Baum"). Eigentlich kann es dort keine derartigen Verlangsamungen geben, zumindest nicht beim Suchen einer Datei.
 
Dass ich das noch erleben darf, juhuu! :)
 
Man konnte seit Jahren schon die Begrenzung überschreiten, wenn man die Dateinamen mit \\.\ angefangen kodiert. Im Programm wohlgemerkt, im Dateisystem (also Explorer-Ansicht) ist das herzlich egal. Nur so mal als Hinweis. Die nächste Frage wäre, wie wirkt sich das auf MAX_PATH aus?
 
@Kirill: Das würde ich allerdings niemandem empfehlen, da nicht alle Win32-APIs Unicode-ready waren und es somit immer zu Problemen kommen konnte. Bestes Beispiel war, dass CreateFile mit Unicode zurechtkam, man also z.B. eine DLL in einem langen Pfad anlegen konnte, LoadLibrary aber z.B. nicht mit Unicode zurechtkam, man die DLL also niemals laden konnte.
 
@HeadCrash: Ernste Frage: Wen interessiert LoadLibrary? LoadLibraryEx kann mehr und kann Unicode.
 
@Kirill: Und dennoch können nicht alle APIs Unicode. Genau das war einer der Gründe, warum MS bisher die Beschränkung nicht aufgehoben hat. Und ich sehe jetzt schon eine Flut von Problemen auf MS zukommen, denn ich lege meine Hand dafür ins Feuer, dass ein nicht gerade geringer Teil von Altapplikationen die Biege machen wird, wenn das Feature aktiv ist. Hatte da mal eine lange Diskussion mit Microsoft zu dem Thema und konnte gut nachvollziehen, warum man das bisher nicht gemacht hat. Ich bin sehr gespannt, welche Mechanismen sie eingebaut haben, um Probleme zu verhindern.
 
@HeadCrash: Was hat \\.\ überhaupt mit Unicode zu tun? Das sind ASCII-Codepunkte. Du kannst also \\.\ völlig frei in ANSI-only-Code nutzen.
 
@Kirill: Siehe https://msdn.microsoft.com/en-us/library/windows/desktop/aa365247(v=vs.85).aspx#maxpath

Die Notation \\?\ weist die win32 an, die Unicode-Versionen der Methoden zu verwenden und funktioniert eben auch nur dort, wo die API Unicode unterstützt.
 
@HeadCrash: Ah, danke für die Info.
 
@Kirill: Vermutlich werden sie die Definition von MAX_PATH nicht verändern, sondern es als deprecated erklären.
Mal schauen, welche Teile der API sie fit für lange Pfadnamen gemacht haben. Als ich vor ca. 1 Jahr zuletzt damit herumprobiert hatte, gab es schon noch so einige Funktionen, die mit langen Pfadnamen ihre Probleme hatten.
 
Bitte auch für 8.1 damit ich "Path Length Checker" nicht mehr brauche.
 
@Paradise: Microsoft wird sicher keine neuen Features für Win 8.1 bereitstellen, du sollst schließlich upgraden!
 
@regulator: Ich soll, habe und bin nach 4 Monaten zurück.
Ob das wirklich ein großes Feature ist wenn die das nachträglich mal so rein hauen können.
Aber vielleicht bekommt man mal wieder eine Neuinstallation - soll einem ja nicht langweilig werden.
 
@Paradise: Notfalls schau Dir mal subst in der CMD an...
 
Endlich :) Manche Anwendungen musste man ins Root Verzeichnis legen, weil die Pfade sonst zu lang wurden :P
 
Von dieser Limitierung wusste ich ehrlich gesagt bisher gar nichts, bin ich auch noch gar nicht begegnet. Aber interessant zu wissen.
 
@FuzzyLogic: Noch nie gehabt das Du einen Ordner nicht löschen konntest weil der Name/Pfad zu lang war?
 
@FuzzyLogic Naja, ich kann mich bis heute nicht erinnern, jemals einen Datei- oder Verzeichnisnamen mit mehr als 20 Buchstaben erstellt zu haben. Und meine Kundendaten werden schon seit Windows 3.1 in eine ordentliche Verzeichnis-Struktur angelegt, so dass solche Dateinamen überhaupt nicht von Nöten sind.
 
Die Pfadlängenbegrenzung im Onedrive aufzuheben fände ich wichtiger, das fällt mir immer wieder auf die Füße. Solche mittelalterlichen Probleme hat die Dropbox nicht.
 
@AkirAdR: Unterschied- Dropbox ist neu entwickelt - OneDrive nur 100 mal umbenannte und immer weiterentwickelter legacy mist. Darum dauert da auch alles so lang bis was gescheites bei rum kommt
 
Was ich mich nun Frage: was ändert Microsoft denn nun eigentlich wirklich?
Die 260 Zeichen sind ja das Pfad-Limit für die Ansi-Version Win32-API ("C:\"+256-Zeichen+Null-Terminator). Die Unicode-Version der Win32-API geht ja schon ewig bis 32768 Zeichen, da dort ja keine Kompatibilität notwendig sondern direkt die native Unicode-API von NT "offengelegt" wurde. Auch dort ist aber jede einzelne Komponente (Pfadname zwischen zwei Backslashs bzw. der Dateiname) limitiert. Meist auf 256 Zeichen, gibt's ne API um rauszufinden wie lang tatsächlich.

Auch das originale Wording klärt das nicht so ganz:
"Enabling NTFS long paths will allow manifested win32 applications and Windows Store applications to access paths beyond the normal 260 char limit per node. Enabling this setting will cause the long paths to be accessible within the process."

"Per node" würde ja letzteres nahelegen. Das ist auch aus Kompatibilitätssicht weniger bedenklich, das Limit war ja eh "dynamisch" definiert, auch wenn das in der Praxis nicht unbedingt der Selbstläufer für Win32-Apps wäre. Wer hat den wirklich sauber mit "GetVolumeInformation" nachgefragt was geht? Store-Apps haben da sicher schon bessere Chancen, .NET und Co. machen das ja wahrscheinlich richtig.
Anderseits war dieses Limit eben 256 Zeichen und nicht 260. 260 galt/gilt eben für die Gesamtpfadlänge bei Verwendung der Ansi-Win32-API, was dann aber weniger "per node" wäre.
 
Naja, die Verwendung von langen Pfaden geht beispielsweise bei CreateFile auch nur mit dem "\\?\"-Prefix. Vielleicht fällt die Verwendung des Prefixes dann einfach weg und es werden lange Pfade auch mit "normaler" Notation akzeptiert.

(Edit: Ja, sieht ganz so aus; ausgewertet wird das neue Flag (RtlAreLongPathsEnabled) beim Parsen des Pfads (in RtlDosPathNameToRelativeNtPathName), und zwar dann wenn der angegebene Pfad länger als 260 (MAX_PATH) ist.)

Übrigens sind Win32- und NT-API nach wie vor zwei verschiedene Dinge. Auch CreateFileW ist also ein Wrapper für NtCreateFile, und keine "direkte Offenlegung" der NT-API.
 
@Garbage Collector: Ich tendiere immer mehr zur Erweiterung der einzelnen Pfad-Segmente bei der Unicode-API. Die maximal akzeptierte Pfadlänge z.B. bei CreateFileA zu erhöhen wäre ja noch das kleinste Problem, in der anderen Richtung bei Queries wirds doch aber heikel. Ich denke Arrays mit MAX_PATH als feste Größenangabe werden kein so seltenes Fundstück sein. Selbst bei den Two-Step-APIs bei denen vorher die Größe abgefragt wird könnte ja jemand unter der Annahme das feststehenden Maximums ja immer noch einen eigenen Allocator verwendet haben, der mehr als 260 Allokationen schlicht nicht unterstützt. Das wäre schon eine brechende API-Änderung, das kann Microsoft bei seinem Kompatibilitätsanspruch eigentlich nicht meinen.

Und ja, natürlich ist Unicode-Win32 formal eine andere API als die NT-API, die sind aber schon verdammt nah aneinander dran. So nah das einige Funktionen nicht mal ein Wrapper mit bissel zusätzlicher Parametervalidierung sind, sondern der DLL Export mit 0 Overhead direkt zur ntdll geforwarded wird...
 
Yeah Baby! Noch mehr Unterordner zum durchklicken ...
 
Wann bringt Winfuture hierzu eine Meldung?
http://www.heise.de/newsticker/meldung/Upgrade-auf-Windows-10-Drueckermethode-wird-noch-aggressiver-3221849.html
 
@daknol: man muss eben nicht jeden SCHEIß aus dem Internet abtippen:
http://www.drwindows.de/content/10257-fenster-schliessen-bedeutet-zustimmung-naechste-maerchen-windows.html
 
Hätte schon vor 20 Jahren kommen müssen. Einfach schwach, der Zustand von Windows. Ein solides, verlässliches System ist mittlerweile echt nur noch Mac und Linux. Bei Windows liegen einfach noch tausende Leichen aus den 90ern im Keller.
 
Super, ich freue mich schon darauf wenn unsere Projektfritzen dann so ultra wichtige Pfade wie $public_share\Projekte\Vertriebsprojekte\Anwendung 2.0\Projektergebnisse\Projektplanung\Lastenheft V1\01.03.2016\Lastenheft V1.docx anlegen. Ultra wichtig!
 
Ich hatte mal eine Zeitungskolumne, die auf 330 Zeichen abzgl. Bildraum begrenzt war. Ging auch! Warum also sollte ich einen kompletten Kolumnentext im Dateinamen unterbringen?
Kommentar abgeben Netiquette beachten!

WinFuture Mobil

WinFuture.mbo QR-Code Auch Unterwegs bestens informiert!
Nachrichten und Kommentare auf
dem Smartphone lesen.

Folgt uns auf Twitter

WinFuture bei Twitter

Interessante Artikel & Testberichte

WinFuture wird gehostet von Artfiles