UNC Pfade + \\?\ MAX_MATH usw. (Win Ver. 1607)

[himitsu]

Jupp, seit Win10 1607 ist die MAX_PATH-Grenze bei vielen APIs inzwischen aufgehoben, auch ohne mit UNC rumspielen zu müssen,
allerdings muß es in der Registry erst aktiviert werden, zusätzlich zum Manifest.
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\FileSystem > LongPathsEnabled

Und nein, neu kompiliert muß nichts werden.
Das Manifest liegt in den Resourcen und Diese lassen sich auch nachträglich noch editieren.
Eventuell muß man noch neu signieren, jedenfalls wenn die EXE signiert war.

[MicMic]

Danke für Eure Anregungen und Infos.
Also wenn das alles erst aktiviert werden muss bzw. ab und zu (wenn es halt noch nicht ist beim Endbenutzer), dann ist der alte Weg ("\\?\" und "\\?\UNC\") wohl besser. Blöd ist aber echt, wenn man vor doofen Problemen steht, die sowieso immer vorhanden sind. Zum Beispiel das laden eines Icons aus EXE-Dateien in so einem langen Pfad. Da geht halt nicht SHGetFileInfo und andere Icon-Routinen wegen MAX_PATH. Die Umwandlung zu einem kurzen Pfad gibt es zwar auch aber es wird beschrieben, dass dies auch nicht immer geht. Bei dem Icon-Beispiel, wäre man wohl nur auf der sicheren Seite, wenn man aus der Exe-Datei den Icon-Header sucht und direkt das Icon mit CreateFile herausliest.

[himitsu]

Ja, ganz früher gab es nur Kurz,
dann wurde Optional zusätzlich noch Lang angehängt (in FAT: in mehreren speziellen "Kurz"-Einträgen auf den originalen Eintrag folgend)

Später wurden im NTFS standardmäßig keine Kurzen Einträge mehr erzeugt, (oder man muß in der Registry die Einstellungen den NTFS-Treiber anpassen und diese Funktion wieder aktivieren)
außer man erstellte die Datei mit der ANSI-API (CreateFileA), bzw. wenn man mit gewissen ANSI-APIs nach Dateien suchte (FindFirstFileA), dann wurde auch noch der Kurzname angelegt (falls nötig)
und aktuell, oder war's zukünftig, soll auch dieses Verhalten entfernt werden (dann nur noch lang).


Und trotzt UNC hat man auch keine Garantie, dass es funktioniert.
* so habe ich in einem ältenen Programm (im Manifest nichts zur Windowskompatibilität) auch mit UNC keinen Zugriff auf längere Pfade

* und selbst im Explorer hatte ich "manchmal" Probleme -> beim Kopieren von NTFS via SMB auf ein Linux, da wurden im Linux alle längeren Pfade ohne Fehlermeldung abgeschnitten
* * geknallt hatte es nur, wenn zufällig ein \ bzw. / als letztes im Datei-Pfad zurück blieb
* * ich weiß aber nicht wer genau es Abschnitt (Windows, SMB oder Linux) ... hatte es versucht rauszubekommen, aber absichtlich zu lange Pfade erzeugt und damit rumgespielt, da ging zufällig immer alles

[Dalai]

Zitat von himitsu:

Und nein, neu kompiliert muß nichts werden.
Das Manifest liegt in den Resourcen und Diese lassen sich auch nachträglich noch editieren.
Eventuell muß man noch neu signieren, jedenfalls wenn die EXE signiert war.

OK, ich formulier's anders: Der Autor einer Software muss (sowieso) eingreifen, ob nun beim Manifest oder im Code. Wenn die Software bisher keine überlangen Pfade unterstützt hat (z.B. weil man überall MAX_PATH genutzt hat), muss die Software neu kompiliert werden, wenn man sicherstellen will, dass sie mit überlangen Pfaden zurechtkommt. Der Weg per Manifest hat den Nachteil, dass dieser Schalter allein nicht ausreicht, weil im System noch ein weiterer umgelegt werden muss, und auch auf älteren Windows-Versionen nicht funktioniert. Das Long Path Prefix funktioniert aber immer und überall (wenn man es richtig nutzt).

Grüße
Dalai