256-Pfadlängenbeschränkung ist in Windows 10 (1607) gefallen

[Bernhard Geyer]

Der Registry-Key funktioniert auch.
Aber wer kann/will hier eine Systemweite Einstellung ändern. Macht man sowas wird man schnell für alle Probleme am PC/Server verantwortlich gemacht ("Sie haben doch da ...")

[generic]

Windows hatte doch noch nie eine Beschränkung von den in der Windows.h angegeben 260 Bytes.
Bei dem Unicode-Windows war es schon im 32k, setzte allerdings voraus, dass du vor den Dateinamen \\?\ eingefügt hast.

Zitat:

The Windows API has many functions that also have Unicode versions to permit an extended-length path for a maximum total path length of 32,767 characters.

Siehe dein Link:
https://docs.microsoft.com/en-us/win.../naming-a-file

[Bernhard Geyer]

Zitat von generic:

... dass du vor den Dateinamen \\?\ eingefügt hast.

Und jetzt 1000 stellen um diesen Präfix ergänzen ... Haben wir uns bisher gespart.
Gab auch nur selten Problem mit der Pfadlänge.
Aber wenn diese jetzt relativ einfach komplett wegfällt - umso besser.

[himitsu]

Selbst mit diesem Pfäfix klappte es nicht immer bei über 260 (255 nur Pfad ohne Laufwerk und abschließendes #0) Zeichen, egal in welcher Combination

C:\...
\\?\C:\...
\\.\C:\...
\\.\$C\...
\\.\ManuellerFreigabename\...
\\:COMPUTERNAME:\$C\...
\\localhost\$C\...
\\localhost\ManuellerFreigabename\...

"Tricksen" konnte man aber oftmals durch Verwendung der kurzen 8.3-Namen (allerdings natürlich nicht für den letzten Namen, beim Erstellen der Datei/Verzeichnis)


\??\...


Aber ich war auch auch froh das letzte Woche schon lesen zu dürfen.

[generic]

Welche Funktionen nutzt du denn?

In der Anleitung seht:

many vs all

Code:

The Windows API has [B]many [/B]functions that also have Unicode versions to permit an extended-length path for a maximum total path length of 32,767 characters. This type of path is composed of components separated by backslashes, each up to the value returned in the lpMaximumComponentLength parameter of the GetVolumeInformation function (this value is commonly 255 characters). To specify an extended-length path, use the "\\?\" prefix. For example, "\\?\D:\very long path".

Nutzt du ein Unicode-Delphi?
Wird wirklich die W-Variante und nicht die A-Version der Funktion aufgerufen?

[himitsu]

Aktuell \\FRANK-AT-WORK\$D\... womit es weniger Probleme gab, als wie mit \\?\D:\...

Ich müsste mal gucken wie lang die Pfade sind, aber ich glaub noch unter 300 Zeichen.
Seit Verwendung der normalen Freigabepfade gibt es gefühlt bei weniger Dateien ein Problem mit zu langen Pfaden.

Selbst zu lange Pfade aus SMB-Freigaben haben mit Pfaden über 255 Zeichen (exklusive Host+Freigabename) probleme, in meinem uralten Windows 7,
egal ob als gemapptes NTFS-Verzeichnis oder direkt als Freigabe, welche ja wohl auch UNC ist.



Also das neue Windows 10 hierbei aber noch nicht ausprobiert.

[generic]

Zitat von himitsu:

Aktuell \\FRANK-AT-WORK\$D\... womit es weniger Probleme gab, als wie mit \\?\D:\...

Hmm, die Schreibweise "$D" kenne ich gar nicht.
Hast du dich hier verschrieben oder nutzt du das so wie du schreibst. Erklärt das evtl. das Problem?

Für die Admin-Shares kenne ich das nur anders herum also "\\localhost\c$".

[CCRDude]

Zitat von himitsu:

Also das neue Windows 10 hierbei aber noch nicht ausprobiert.

Weiss nicht ob das aufgefallen ist... aber es geht um eine mehr als zwei Jahre alte Änderung - 1607 bedeutet Juli 2016!

[Assarbad]

Zitat von himitsu:

Aktuell \\FRANK-AT-WORK\$D\... womit es weniger Probleme gab, als wie mit \\?\D:\...

\\.\D$ ... sollte unter Umständen auch funktionieren. Der Punkt ist hier Platzhalter für den aktuellen Rechnernamen. Ist vielleicht etwas unkomplizierter als diesen vorab zu ermitteln.

Übrigens würde ich allen, die des Englischen mächtig sind, folgende Lektüre ans Herz legen: The Definitive Guide on Win32 to NT Path Conversion. Das erklärt einiges rund um das Thema, wenn auch nicht exakt die Frage oben. Einiges davon kann man sich dann auch näher mit meinem ntobjx oder mit WinObj von Sysinternals anschauen. Ach ja und das hier ist vielleicht auch noch sinnvoll.

Ja, der Grund warum eine Anwendung selbst (über das Manifest) kundtun sollte, daß sie lange Pfadnamen versteht, sollte klar sein. Schaut man sich Funktionen wie GetFullPathName sind dokumentiert mit MAX_PATH als maximal zulässiger Länge. Wenn sich also die Entwickler daran hielten, haben die auch nur das was damals MAX_PATH war reserviert. Bei dieser Funktion wäre es unproblematisch, aber ich entsinne mich, daß es Funktionen gibt, bei denen als Eingabe keine Maximallänge des Puffers vom Aufrufer mitgegeben wird und dann fehlt der aufgerufenen Funktion natürlich die Info, ob das Programm bereits mit langen Pfaden kompatibel ist oder nicht. Daher ist das Manifest eine sinnvolle Möglichkeit dem OS zu kommunizieren was Fakt ist.

Zitat von Whookie:

Daher bringt der Manifest-Eintrag wohl eher längerfristig was, wer aktuell mit langen Pfaden arbeiten möchte muss wohl die \\?\ verwenden.

Das ist richtig.

Zitat von Whookie:

Für mich lasse ich aber momentan lieber die Finger davon - solange das OS keine vollständige Unterstützung bietet ist das Risiko Daten damit zu verstümmeln einfach zu groß.

Kannst du das bitte nochmal erklären? Das erscheint mir auf einem Mißverständnis aufzubauen. Wenn du Unicode schon heute benutzt, kannst du sinnvollerweise schon heute davon profitieren, aber eben mit nem Präfix. Da verstümmelt dir das OS nix. Das OS unterstützt so einiges, was Win32-Programmierer üblicherweise nicht zu Gesicht bekommen (bspw. Datei-/Pfadnamen die sich nur in Groß-/Kleinschreibung unterscheiden). Mit dem Präfix bist du sozusagen näher am OS, aber der einzige Grund warum MAX_PATH früher 260 Zeichen war, ist, daß Windows 9x/Me auch unterstützt werden mußte. Und so hat man aus Kompatibilitätsgründen die Pfadlänge der Win32-Funktionen auf NT begrenzt. Viele Beschränkungen auf den NT-basierenden Systemen sind dieser dogmatischen Rückwärtskompatibilität geschuldet. Hier hätte Microsoft auch den Weg von SUS/POSIX einschlagen können und bspw. ausschließlich auf Quelltextkompatibilität setzen können. Allerdings hättest du dann für jede größere neue Windowsversion ne eigene EXE auszuliefern.

Wer hält dich davon ab einen PWideChar-Puffer immer mit \\?\ vorzubefüllen? Du kannst ja beim Aufruf der entsprechenden API-Funktionen ganz einfach diese 4 "verbrauchten" Zeichen abziehen und @lpPath[4] übergeben, oder? Ohnehin schreiben Pfade ja quasi danach als Objekte behandelt zu werden. So gesehen böte sich an die eigenen Pfadklassen einfach aufzubohren - da muß niemand tausende Quelltextstellen anpassen

Abgesehen davon ist die maximale Pfadlänge ohnehin eine eher verschwommene Angelegenheit. Die 32767 Zeichen sind Maximum und haben damit zu tun, daß UNICODE_STRING (der gezählte Stringtyp der bspw. in der NT Native API und damit auch im Kernelmode benutzt wird) eine 16-bittige vorzeichenlose Ganzzahl als Zähler (in Bytes! nicht Zeichen!) benutzt. Davon kann man pauschal gleich schonmal die vier Zeichen für den Präfix abziehen und eins für die ASCII-Null am Ende. Und der Präfix wird normalerweise auch nochmal expandiert (siehe verlinkter Artikel oben und ntobjx).

[Bernhard Geyer]

Zitat von generic:

Nutzt du ein Unicode-Delphi?

Gibts noch andere

Wir sind auf Delphi 10.2. Alles Unicode.