Einzelnen Beitrag anzeigen

Benutzerbild von Assarbad
Assarbad

Registriert seit: 8. Okt 2010
Ort: Frankfurt am Main
1.178 Beiträge
 
#24

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

  Alt 16. Okt 2018, 15:18
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 MSDN-Library durchsuchenGetFullPathName sind dokumentiert mit MSDN-Library durchsuchenMAX_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.

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.

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ß MSDN-Library durchsuchenUNICODE_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).
Oliver
"... aber vertrauen Sie uns, die Physik stimmt." (Prof. Harald Lesch)

Geändert von Assarbad (16. Okt 2018 um 15:47 Uhr) Grund: Anderen Beitrag verlinkt
  Mit Zitat antworten Zitat