GetFileSize - welches ist die bessere Funktion?

[Benmik]

Zitat von jbg:

Man kann bei WinAPI.Windows.CreateFile() statt GENERIC_READ ein FILE_READ_ATTRIBUTES mitgeben.

Wenn ich die Dokumentation richtig verstehe, ist 0 sogar noch besser:

Zitat:

Wenn dieser Parameter null ist, kann die Anwendung bestimmte Metadaten wie Datei-, Verzeichnis- oder Geräteattribute abfragen, ohne auf diese Datei oder das Gerät zuzugreifen, auch wenn GENERIC_READ Zugriff verweigert worden wäre.

[jbg]

Zitat von Benmik:

Wenn ich die Dokumentation richtig verstehe, ist 0 sogar noch besser

Hat mich jetzt mal interessiert, was denn der Unterschied ist. Und siehe da...

Im Code von CreateFileW wird vor dem Aufruf von NtCreateFile der "Access" Parameter mit 0x00100080 ge-OR-t. Das wäre also NtCreateFile(Access or (SYNCHRONIZE or FILE_READ_ATTRIBUTES), ...).

Zitat:

or eax,$00100080
push dword ptr [esp+$1c]
mov [esp+$28],eax
push dword ptr [ebp+$08]
push ecx
push $00
lea ecx,[esp+$40]
push ecx
lea ecx,[esp+$0080]
push ecx
push eax
lea eax,[esp+$48]
push eax
call dword ptr [$768700c4] => NtCreateFile

Auch im wine Code findet man dies.

0 hat also die gleiche Bedeutung wie "SYNCHRONIZE or FILE_READ_ATTRIBUTES". Es ist jetzt also nur Geschmackssache ob "CreateFile(FILE_READ_ATTRIBUTES, ...)" oder "CreateFile(0, ...)" eine besser Aussage trifft, was die Intention des Codes ist.

[himitsu]

Zitat von Benmik:

Leider kann ich keine der C-Sprachen. Dort ist die Code-Situation viel günstiger

Was "nativ" in C/C++ geht, geht auch im Delphi, also wenn es direkt um die WinAPI geht, ohne Wrapper ala RTL, VCL oder von Fremden drumrum.
Wir nutzen die selbe WinAPI, also lässt sich nahezu alles ins Pascal/Delphi übersetzen, bzw. wir können in C-Codes abgucken.

Unterschied ist nur, dass in Delphi nicht alles "deklariert" ist (Borland/Emba war/ist zu faul dafür), da wir es in unserer Syntax (Delphi-Language) benötigen und wir nicht einfach so C-Header-Files importieren können.
OK, stimmt nicht ganz, denn WinMD stellt es uns automatisch übersetzbar zur Verfügung, wenn es denn irgendwann mal funktioniert. https://www.delphipraxis.net/214473-...vor-winmd.html
Wobei C-Compiler oft einfach direkt die Header-Files nutzen können, welche Microsoft für Windows bereit stellt (MSDN bzw. PSDK/WinSDK).

Leider geht es bei "Delphi" nur andersrum ... es lassen sich Delphi-Units im C++Builder nutzen,
aber leider keine Dateien/DCU vom C++Builder im Delphi (inkl. fremder HeaderFiles und Codes) ... also das wäre echt mal ein sinnfolles Feature.

[Benmik]

Zitat von jbg:

Im Code von CreateFileW wird vor dem Aufruf von NtCreateFile der "Access" Parameter mit 0x00100080 ge-OR-t. Das wäre also NtCreateFile(Access or (SYNCHRONIZE or FILE_READ_ATTRIBUTES), ...).
...
0 hat also die gleiche Bedeutung wie "SYNCHRONIZE or FILE_READ_ATTRIBUTES".

Das war jetzt erstmal eine Kopfnuss, diese Bitmasken zu sortieren und gedanklich für OR übereinander zu stellen. Aber tatsächlich geht CreateFile mit 0 oder FILE_READ_ATTRIBUTES durch, auch wenn die Datei durch eine vorherige Öffnung mit GENERIC_READ or GENERIC_WRITE, 0, komplett blockiert ist. Im Gegenzug kann man den Parameter dwShareMode auf 0 setzen, da er bei FILE_READ_ATTRIBUTES ignoriert wird, also hFind := CreateFile(PChar(Dateiname), FILE_READ_ATTRIBUTES, 0, nil,OPEN_EXISTING, FILE_ATTRIBUTE_NORMAL, 0);

Mir erscheint dann ein FILE_READ_ATTRIBUTES anschaulicher, da hast du recht.

Mir fällt übrigens noch ein, dass ich einen Leer-Aufruf von GetFileInformationByHandle auch nach CreateHardLinkW benutze, da laut Doku dann die Dateiinformationen aktualisiert werden.