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