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

[himitsu]

Blöd ist nur, dass diese $-Freigaben versteckt sind und in den Eigenschaften des Laufwerks nicht angezeigt werden.
Drum werden viele wohl nicht wissen, dass man da was löschen könnte.

[Dalai]

[OT]

Die administrativen Freigaben kommen sowieso von selbst wieder:

Zitat:

---------------------------
Freigegebene Ordner
---------------------------
Diese Freigabe wurde nur für Verwaltungszwecke erstellt. Diese Freigabe wird wieder eingeblendet, wenn der Serverdienst beendet und neu gestartet wird oder wenn der Computer neu gestartet wird. Soll B$ nicht mehr freigegeben werden?
---------------------------
Ja Nein
---------------------------

Insofern muss man schon per Gruppenrichtlinien bzw. Registry rangehen, wenn man die permanent loswerden will. Es bleibt aber die Frage, warum man die Freigaben unbedingt loswerden will, wenn sowieso nur der Admin Zugang hat.

[/OT]

Grüße
Dalai

[Whookie]

Um auf das ursprüngliche Thema zurückzukommen. Ich habe das hier auf einem Windows 2016 Server und auf Windows 10 ausprobiert.

Der Registrykey hebt die 260-Zeichengrenze nicht auf. Er muss aber gesetzt werden, damit der im Manifest vorhandene <longPathAware> - Eintrag berücksichtigt wird.
Die Powershell arbeitet zum Beispiel auf diese Weise (im Gegensatz zum Explorer) und kann dann mit überlangen Dateinamen umgehen und auch in eigenen Programmen funktioniert das dann.

Unabhängig davon funktioniert die Verwendung von \\?\.

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

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ß.

[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).

[Memnarch]

Die LongPathes gibt es schon eine ganze Weile in Windows. Einfach überall "\\?\" vorklatschen funktioniert aber nicht. Der Präfix entfernt zwar das Längenlimit von 260 Charakter, leider aber auch das Postprocessing von Pfaden. Mit entsprechenden Windowsapi-Funktionen kann man einen Pfad zuvor normalisieren. Bei uns habe ich damals extra einen Datentyp eingefügt, der dies Implizit macht. So kann man den Datentyp als Parameter für die Stellen verwenden, an denen es wichtig ist. Der Pfad selber ist aber bis dahin ein "normaler" Pfad. Generell empfiehlt es sich erst dann in den Longpath zu wandeln, wenn man auch wirklich auf Dateien zugreifen muss.

[Assarbad]

Zitat von Memnarch:

Einfach überall "\\?\" vorklatschen funktioniert aber nicht. Der Präfix entfernt zwar das Längenlimit von 260 Charakter, leider aber auch das Postprocessing von Pfaden.

Was genau meinst du denn mit Postprocessing von Pfaden? Ich kenne leider nur das Expandieren auf Ebene des Object Managers. Und das funktioniert schon seit NT 3.51 tadellos mit langen Pfadnamen, denn unterhalb des Win32-Subsystems ist das die Normalität. Abgesehen davon hat man auch auf Win32-Ebene die Option \??\ als Präfix zu benutzen um bestimmte Logiken im Betriebssystem zu umgehen.

Zitat von Memnarch:

Mit entsprechenden Windowsapi-Funktionen kann man einen Pfad zuvor normalisieren.

Beispiel? Was genau meinst du hier? Umwandlung von relativen in absolute Pfade? Also im Grunde GetFullPathName und die nativen Freunde davon, welche in dem oben verlinkten Artikel erwähnt werden?

Zitat von Memnarch:

Bei uns habe ich damals extra einen Datentyp eingefügt, der dies Implizit macht.

Und genauso macht man das auch , es sei denn es ist anderweitig in der Logik verankert.

Zitat von Memnarch:

Generell empfiehlt es sich erst dann in den Longpath zu wandeln, wenn man auch wirklich auf Dateien zugreifen muss.

Warum? Was ist denn schädlich daran generell mit langen Pfadnamen zu arbeiten? Denn wenn sich eine Empfehlung ergibt, scheint es ja einen Nachteil bei der Nutzung langer Pfadnamen zu geben. Mit ist kein Nachteil bekannt, bin daher auf die Antwort schon gespannt.

Ach ja, noch als Nachtrag zu meinem vorherigen Beitrag: shlwapi ist beispielsweise ganz schlimm in Sachen hartkodierte Beschränkung auf MAX_PATH, ebenso weitere Teile der "Shell", während bspw. WIN32_FIND_DATA wieder harmlos ist, weil es hier um ein einziges Segment des Pfads geht und eben nicht um den gesamten Pfad. Das soll an Beispielen erst einmal reichen.

[Whookie]

Zitat von Assarbad:

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. ...

Natürlich nicht mit der eigenen Applikation aber durch andere, die dann damit nicht zurecht kommen, dass sich die Dateien in für sie zu langen Pfaden verstecken.

Konkretes Beispiel: Eine kaum benutzte Dateizusammenstellung wurde von einem unserer Admins mit einer ältlichen Version eines Packprogrammes "in Sicherheit gebracht" und aus platzgründen vom Server gelöscht.
Nur knapp zwei Jahre später war dann doch eine Zugriff darauf nötig. Nach dem entpacken war allerdings das Erstaunen (und das Wehklagen) groß, denn im Archiv war nichts mehr drin, was tiefer als ~260 Zeichen gelegen hatte...

[Schokohase]

Zitat von Whookie:

Konkretes Beispiel: Eine kaum benutzte Dateizusammenstellung wurde von einem unserer Admins mit einer ältlichen Version eines Packprogrammes "in Sicherheit gebracht" und aus platzgründen vom Server gelöscht.
Nur knapp zwei Jahre später war dann doch eine Zugriff darauf nötig. Nach dem entpacken war allerdings das Erstaunen (und das Wehklagen) groß, denn im Archiv war nichts mehr drin, was tiefer als ~260 Zeichen gelegen hatte...

Das ist das gleiche Dilemma wie bei den ganzen Backup-Tools. Man muss ebenso regelmäßig wie das Backup selber auch die Wiederherstellbarkeit dessen überprüfen. Das kostet allerdings Zeit und Geld und wird darum gerne vernachlässigt.

[Whookie]

Zitat von Schokohase:

Das ist das gleiche Dilemma wie bei den ganzen Backup-Tools. Man muss ebenso regelmäßig wie das Backup selber auch die Wiederherstellbarkeit dessen überprüfen. Das kostet allerdings Zeit und Geld und wird darum gerne vernachlässigt.

Ja ich habe dar schon ein paar Dinge gesehen, die zum Haare raufen sind.

[Assarbad]

Zitat von Whookie:

Konkretes Beispiel: Eine kaum benutzte Dateizusammenstellung wurde von einem unserer Admins mit einer ältlichen Version eines Packprogrammes "in Sicherheit gebracht" und aus platzgründen vom Server gelöscht.
Nur knapp zwei Jahre später war dann doch eine Zugriff darauf nötig. Nach dem entpacken war allerdings das Erstaunen (und das Wehklagen) groß, denn im Archiv war nichts mehr drin, was tiefer als ~260 Zeichen gelegen hatte...

Aaaaah, alles klar

Jupp, wer seine Backups nicht prüft, dem blühen derlei Probleme. Wobei ich mich dann noch fragen würde wo der Admin sein Handwerk gelernt hat. Aber wir hatten und haben derlei Admins auch in der Firma. Ich hab aus Spaß mal selbst die Stichprobe gewagt und von meinen Dateien auf dem gemeinsamen Dateiserver ein paar Dateien gelöscht. Etwa ein halbes Jahr später habe ich dann darum gebeten die Dateien wiederherzustellen. Ratet mal was ich als Antwort bekam. Erste Reaktion: "Das geht nicht!". Zweite Reaktion auf meine Rückfrage: "Man kann die Backups nur wieder komplett einspielen". Na supi. Da hat jemand bei der Auswahl des Backupsystems mitgedacht. Ich meine sogar Bandlaufwerke hatten ehemals die Möglichkeit einzelne Dateien wiederherzustellen, auch wenn es ein langwieriger Prozeß war (wegen hin- und herspulen). Aber Hauptsache ein Admin trabt treudoof jede Woche mit nem "Backup" zum Ort der (bezahlten) sicheren Verwahrung. Kreuzchen auf dem Fragebogen "Machen Sie regelmäßige Backups" kann damit auch gemacht werden. Wiederherstellung ist dann hoffentlich Problem der Nachfolger. IT 3.0!

Aber zurück zum Thema. Umso wichtiger finde ich eigentlich, daß man lange Pfade auch heute schon unterstützt und nicht erst in zwei Jahrzehnten.

Mit Junction Points kann man übrigens wunderbar auch Programme die nicht langer Pfade mächtig sind - zu einem gewissen Grad - austricksen. Besser noch, man kann mit Junction Points Pfade erzeugen die dann intern auf riesige Längen expandiert werden. Und das ganz ohne Hilfe von Präfixen.