Woher weiß ich die Puffergröße für einen Aufruf?

[Der schöne Günther]

Danke für den seelischen Beistand, dann ist das wohl wirklich etwas komisch.


Ich nehme einfach 32 KB, die (momentan) maximale Pfadgröße

[Assarbad]

Zitat von Der schöne Günther:

Ich nehme einfach 32 KB, die (momentan) maximale Pfadgröße

Dazu noch einen kleinen Exkurs. Es ist in der Tat die absolut größte Pfadlänge im Moment.

Die Obergrenze stammt daher, daß UNICODE_STRING einen 16-bittigen vorzeichenlosen Integertyp (in Delphi: Word) benutzt um die Puffergröße in Bytes zu hinterlegen.

Während ehemals Windows NT UCS2 meinte wenn Unicode draufstand (also exakt ein WideChar pro Codepunkt), erweitern moderne Windowsversionen dies auf UTF-16, wodurch Zeichen außerhalb des Unicode BMP zum kodieren eines Codepunkts mehr als ein WideChar brauchen.

Ein Pfadname kann also durchaus kürzer sein als es die Länge in WideChar vermuten lassen würde.

Das eigentliche Thema ist aber die Erweiterung der Pfadnamen im Kernelmodus.

Haste beispielsweise die Datei C:\bootmgr, wird das bei der Benutzung von langen Pfadnamen laut Naming Files ("Naming Files, Paths, and Namespaces") zu \\?\C:\bootmgr, welches für die nativen Schnittstellen schwuppdiwupp in \??\C:\bootmgr verwandelt wird. Wobei \?? auf modernen Systemen (alle mit eingebauten TS) ein Alias für \GLOBAL?? ist, worin die "DOS"-Gerätenamen abgelegt werden. Es gibt dann noch sitzungsspezifische Alternativen zu \GLOBAL?? (falls dich das interessiert kannste mein kleines Tool hier benutzen - .exe ist AuthentiCode-signiert [1]). Einerlei, in \GLOBAL?? gibt es dann bspw. einen symbolischen Link namens C: der bei mir auf \Device\HarddiskVolume6 zeigt, wodurch aus deinem Pfad \Device\HarddiskVolume6\bootmgr wird. Aus diesem Grund ist die echte Obergrenze für die Pfadlänge unterhalb der 32k anzusiedeln. In Windows ist sie auf 0xFFF0 (dann in Bytes) festgelegt und der Rückgabewert für diesen Fehlerfall ist ERROR_FILENAME_EXCED_RANGE (bzw. intern STATUS_NAME_TOO_LONG). Aber einen exakten Wert für den Benutzermodus kann man so dennoch nicht angeben. Nur das absolute Maximum, bedingt durch die gezählten Strings (UNICODE_STRING) im Kernelmodus.

Die eigentliche Obergrenze ist also etwas schwammig, weil sie davon abhängt die lang der Gerätename im Namensraum des Objektmanagers ist.

MSDN weist auch drauf hin:

Zitat:

Note The maximum path of 32,767 characters is approximate, because the "\\?\" prefix may be expanded to a longer string by the system at run time, and this expansion applies to the total length.

[1] Als Alternative zu vorgenanntem Programm kann ich noch das hier anbieten. Ich hoffe es kompiliert auf modernem Delphi, ansonsten schickt nen Pull-Request, den ich dann auf einen alternativen Zweig schieben würde. Das ist ein Programm welches Marcel van Brakel und ich 2005 für die Märzausgabe 2006 von The Delphi Magazine entwickelt hatten und zu dem es auch noch einen Artikel mit Erklärungen gab. Auch freue ich mich über Rückmeldungen/Fehlermeldungen zu ntobjx.

[Luckie]

Es sind nicht nur unterschiedliche Windows Versionen, warum die API nicht konsistent ist. Teilweise liegt es auch daran, dass unterschiedliche Teams an dem gleichen System gearbeitet haben.

[himitsu]

Im Prinzip kann man auch eine Repeat-Schleife um den Aufruf machen, wenn sich die Puffergröße zu schnell ändern könnte.
Mit Len=0 die Schleife beginnen, oder gleich blind schonmal paar Bytes bereitstellen, und wenn nicht groß genug, dann die Schleife mit größerem Speicher durchlaufen.

Im Normalfall reichen ja auch zwei aufeinanderfolgende Aufrufe mit nil+0 und dann nochmal mit @buff+len,
aber es gibt auch APIs, die zwar irgendein ERROR_INSUFFICIENT_BUFFER liefern, wenn zu klein, es aber nicht erlauben, dass man NIL+0 rein gibt, um erstmal nur nach der Größe zu fragen.

Bezüglich der erwähnten Prozesslisten kann es auch sein, dass der Aufruf dennoch erfolgreich ist, auch wenn de Puffer zu klein war. (gilt auch für andere APIs, die 'ne Art Record-Array liefern)
Da bekommt man dann einfach nur die x Prozesse aufgelistet, die in den Puffer passen.
Oftmals kann man bei sowas dann aber auch noch einen Offset reingeben, um in Folgeaufrufen weitere Prozesse abzufragen.
Also z.B. statt alle 200.000 auf Einmal einfach immer nur je 1000, bis man dann Alle hat.

PS: MAX_PATH ist zwar 260, aber eigentlich ist der "maximale Pfad" nur 256 inkl. der abschließenden #0. (das DRIVE "X:\" gehört ja eigentlich nicht zum PATH, im jeweiligen Gerätetreiber)

[Assarbad]

Zitat von himitsu:

(das DRIVE "X:\" gehört ja eigentlich nicht zum PATH, im jeweiligen Gerätetreiber)

Der Backslash schon noch, aber nicht mehr alles danach. Richtig.