GetFileSize - welches ist die bessere Funktion?

[jaenicke]

Zitat von Benmik:

Schwer zu verstehen. Wie soll das gehen, nicht alle einzeln abzufragen? Ein Test mit dem direkten Aufruf von FindFirstFileExW ergab Zeiten zwischen 13 und 19 Sekunden, also wesentlich langsamer als GetFileAttributesEx.

Du fragst aber nicht etwa jede Datei einzeln so ab, oder?

Es geht ja eben darum, dass du die Anzahl der Abfragen reduzierst. Sprich dass du auf diese Weise gleich alle Dateien in einem Verzeichnis durchgehst.

[Benmik]

Wie soll ich die nicht alle einzeln abfragen? Ich brauche die Daten für jede einzelne Datei. Ich habe eine Klasse TDat und eine TObjectList<TDat> , lese die Dateien mittels TDirectory.GetFiles in ein TStringDynArray ein und lege für jede Datei eine Instanz von TDat an. Bisher habe ich das mit GetFileInformationByHandle gemacht und von allen Dateien die entsprechenden Felder gefüllt; jetzt denke ich, dass ich viel Zeit spare, wenn ich mit GetFileAttributesEx erst einmal die herausfiltere, deren Bytegröße nur einmal vorkommt, und erst dann die verbliebenen mit GetFileInformationByHandle bearbeite. Das wäre nicht nötig, wenn der Defender Antivirus die Aktion nicht so wahnsinnig verlangsamen würde, aber da ist vermutlich nichts zu machen.

[Uwe Raabe]

Du könntest das TDirectory.GetFiles overload nehmen, das ein TFilterPredicate akzeptiert. In dem Filter hast du Zugriff auf SearchRec.Size.

[jbg]

Wie öffnest du das File-Handle für GetFileInformationByHandle? Man kann bei WinAPI.Windows.CreateFile() statt GENERIC_READ ein FILE_READ_ATTRIBUTES mitgeben. Dann ist CreateFile um einiges schneller. Und der Defender weiß, dass du dich nicht für den Inhalt der Datei interessierst.

Ein Test mit 69669 Dateien liefert bei mir:

Mit FILE_READ_ATTRIBUTES (Kalt):

CreateFile	1,696 Sekunden
GetFileInformationByHandle	0,275 Sekunden
CloseHandle	0,353 Sekunden

Mit GENERIC_READ (Kalt) (Defender braucht einen ganzen CPU-Kern):

CreateFile	217,032 Sekunden
GetFileInformationByHandle	0,451 Sekunden
CloseHandle	0,428 Sekunden

Übrigens die JclNTFS.pas NtfsGetHardLinkInfo Funktion nutzt GENERIC_READ, was sie somit auch extrem langsam macht, wenn ein Virenscanner vorhanden ist.


Hier der korrigierte JclNTFS.pas Code:

Delphi-Quellcode:

function NtfsGetHardLinkInfo(const FileName: string; var Info: TNtfsHardLinkInfo): Boolean;
var
  F: THandle;
  FileInfo: TByHandleFileInformation;
begin
  Result := False;
  F := CreateFile(PChar(FileName), {-->}FILE_READ_ATTRIBUTES{<--}, FILE_SHARE_READ or FILE_SHARE_WRITE, nil, OPEN_EXISTING, 0, 0);
  if F <> INVALID_HANDLE_VALUE then
  try
    ResetMemory(FileInfo, SizeOf(FileInfo));
    if GetFileInformationByHandle(F, FileInfo) then
    begin
      Info.LinkCount := FileInfo.nNumberOfLinks;
      Info.FileIndexHigh := FileInfo.nFileIndexHigh;
      Info.FileIndexLow := FileInfo.nFileIndexLow;
      Result := True;
    end;
  finally
    CloseHandle(F);
  end
end;

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

[Benmik]

@Uwe Raabe: Jesus Christus. Das drückt die Zeit auf 2 Sekunden bei Neustart; bei Zweitstart und ausgeschaltetem Defender auf 0,7 Sekunden. Ganz abgesehen davon, dass man die Dateien ja sowieso einlesen muss.

Jetzt erinnere ich mich auch, dass ich damals das SearchRec bei Predicate gesehen hatte, aber das wäre mir im Leben nicht mehr eingefallen. Alle Achtung, Herr Raabe.

[Benmik]

Andreas, das ist natürlich auch genial. Und das Beste ist, dass ich es mit Uwes Rat kombinieren kann.
Meine Ergebnisse sind:

DateiInfoByHandle

Neustart mit Defender	20 sec
Neustart ohne Defender	12 sec
Zweitstart mit Defender	19 sec
Zweitstart ohne Defender	19 sec

Interessant, dass die Routine nach einem Neustart sogar schneller ist, aber dafür gibt es vermutlich auch eine Erklärung.

Erst jetzt fällt mir auf, dass es auch GetFileInformationByHandleEx mit dem Parameter FileInformationClass gibt. Da wäre FileIdInfo interessant, das aber leider nicht die Anzahl der Hardlinks mitliefert, die ich brauche. Anscheinend gibt es aber die Ex-Version nicht bei Delphi. Könnte man nachbauen, aber ist für mich vermutlich unnötig.

Jedenfalls bin ich ein großes Stück weitergekommen, hätte ich nicht gedacht. Vielen Dank euch beiden.

Offtopic: Ich bin immer noch ein ganz großer Fan von AsyncCalls und habe es nach wie vor in Verwendung.