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

[Bernhard Geyer]

Ist das schon jemand aufgefallen bzw. hat er sein programm (per Manifest) erweitert

Laut MSDN würde folgender Manifest-Ergänzung genügen
um die 256-Pfadlängengrenze für die eigene Anwendung verschwinden zu lassen

Code:

<application xmlns="urn:schemas-microsoft-com:asm.v3">
    <windowsSettings xmlns:ws2="http://schemas.microsoft.com/SMI/2016/WindowsSettings">
        <ws2:longPathAware>true</ws2:longPathAware>
    </windowsSettings>
</application>

Hat das schon jemand gemacht und kann er Erfahrungen posten?

[Der schöne Günther]

Ooh, ich dachte immer mit dem Registry-Schlüssel hätte man automatisch alle Anwendungen mit diesem Verhalten beglückt, das wäre ja katastrophal. Dass man das noch mit dem Manifest zusätzlich noch freischalten muss hatte ich überlesen.

[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:

Zitat von generic (Beitrag 1414872)

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

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.

[Bernhard Geyer]

Zitat:

Zitat von generic (Beitrag 1414883)

Nutzt du ein Unicode-Delphi?

Gibts noch andere :stupid:

Wir sind auf Delphi 10.2. Alles Unicode.

[himitsu]

Die Programme wo ich meistens die Probleme bemerke, wurden zuletzt in XE kompiliert,
aber auch als sie noch Delphi 7 waren, wurde dort schon mit den Unicode-APIs gearbeitet. (FindFirstFileW, CreateFileW, DeleteFileW usw.)

[generic]

Zitat:

Zitat von himitsu (Beitrag 1414884)

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

[DieDolly]

Ich habe kein Windows 10. Aber funktioniert ein vorangestelltes \\?\ trotzdem noch, um einen langen Pfad zu nutzen?
Schade, dass MS solch wirklich sinnvollen Sachen nicht noch schnell in Windows 7 einbauen.

[Delphi.Narium]

Zitat:

Zitat von generic (Beitrag 1414973)

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

Admin-Shares =

Delphi-Quellcode:

"\\Rechnername\Laufwerksbuchstabe$"

oder

Delphi-Quellcode:

"\\IP-Adresse\Laufwerksbuchstabe$"

ergibt beim eigenen Rechner halt u. a.

Delphi-Quellcode:

"\\localhost\c$"

aber auch

Delphi-Quellcode:

"\\127.0.0.1\c$"

sollte gehen.

[Bernhard Geyer]

Zitat:

Zitat von DieDolly (Beitrag 1414979)

Schade, dass MS solch wirklich sinnvollen Sachen nicht noch schnell in Windows 7 einbauen.

Wieso sollte das MS machen? In 2 Jahren bekommt (aktueller Stand) Win7 keine Updates mehr.

[DieDolly]

Weil es noch immer Leute gibt, die Windows 7 besser finden als Windows 10. Ich bin einer davon. Windows 10 ist zu überladen, die Updatepolitik ist nicht gut und am PC sieht es trotzdem noch immer alles aus, als ob es für Touch optimiert wäre. Genau wie Windows 8 eben.

[Bernhard Geyer]

Zitat:

Zitat von DieDolly (Beitrag 1414995)

Weil es noch immer Leute gibt, die Windows 7 besser finden als Windows 10.

Und? Es gibt auch Leute die NT besser finden als alles danach.
Für MS ist alles < Win10 mehr oder minder gestorben. Finde dich damit ab.
Featureupdates gibt jeweils nur im halbjährlichen Windows-Featureupdate.

Aber das ist alles OffTopic.
MS hat es endlich gemacht und gut ist.

Die initale Frage ob es jemand schon gemacht hat und wie seine Erfahrungen sind.

[himitsu]

Jupp, sorry, hatte mich hier verschrieben.

Nutzen tue ich das mit dem $ am Ende. :oops:

[CCRDude]

Zitat:

Zitat von himitsu (Beitrag 1414884)

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!

[himitsu]

Mein heimisches Entwicklungsrechner-Windows 7 hat schon paar Jahre auf dem Buckel. (hiergendwie hat nie jemand Lust den mal neu aufzusetzen :stupid:)

Lebe da zeitlich eh hinterm Mond.
Hatte auch vor Kurzem erst mitbekommen, dass mein mir jahrelang bekannter Externer-Festplatten-Bug (ab und an winzige Datenfehler bei Schreiben/Lesen von über 100GB)
eigentlich ein USB 3.0-Bug der ersten Generation ist, der auch Datenfehler in TCP/IP schmuggelt, wenn ein LAN-USB-Adapter verwendet wird (hier sind die TCP/IP-Prüfsummen im Adapter drin behandelt, bevor es ohne weitere Checks in den Rechner geht).
Da ist ab und an ein Frame (jeweils 8 Byte) im USB-FullSpeedTransfer defekt, welcher aber unbemerkt durchflutscht.

Aber nö, war nicht so aufgefallen ... letzte Woche erfahren und blind angenommen es beziehe sich auf das große Oktoberupdate.



Und, wie gefällt euch das nagelneue Windows? (weiter in anderem noch nicht erstellten Thread)

[jobo]

Zitat:

Zitat von himitsu (Beitrag 1415004)

Jupp, sorry, hatte mich hier verschrieben.

Nutzen tue ich das mit dem $ am Ende. :oops:

Ja, es gibt glaube ich noch mehr, nicht nur je Laufwerk.

Das kann praktisch sein, aber es bedeutet am Ende auch nur, dass man zu faul ist, zielgerichtet eigene Shares anzulegen und mit spezifische Accounts anzulegen und zu nutzen. Sprich, man arbeitet als Admin oder Admingruppenmitglied auf dem System, was man m.E. nachwievor/mehrdennje vermeiden sollte.

Es soll Leute geben, die diese Freigaben extra löschen, wenn sie einen neuen Rechner in die Finger kriegen.

[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. :stupid:

[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:

Zitat von himitsu (Beitrag 1414884)

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:

Zitat von Whookie (Beitrag 1415289)

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:

Zitat von Whookie (Beitrag 1415289)

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 :zwinker:

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:

Zitat von Memnarch (Beitrag 1415981)

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:

Zitat von Memnarch (Beitrag 1415981)

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:

Zitat von Memnarch (Beitrag 1415981)

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

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

Zitat:

Zitat von Memnarch (Beitrag 1415981)

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:

Zitat von Assarbad (Beitrag 1415878)

Zitat:

Zitat von Whookie (Beitrag 1415289)

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:

Zitat von Whookie (Beitrag 1416013)

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:

Zitat von Schokohase (Beitrag 1416018)

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:

Zitat von Whookie (Beitrag 1416013)

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 :lol:

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! :wink:

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.

[TurboMagic]

Die einfachste Lösung wäre doch denke ich, gar nicht so lange Pfade zu benutzen... ;-)

[Assarbad]

Zitat:

Zitat von TurboMagic (Beitrag 1417702)

Die einfachste Lösung wäre doch denke ich, gar nicht so lange Pfade zu benutzen... ;-)

Also wenn wir schon dabei sind, dann bitte auch 8.3-Dateinamen wieder einführen. Die aktuell möglichen Dateinamen sind deutlich zu deskriptiv. :lol: