TWin32FindData: Dateigröße bestimmen

[Jim Carrey]

Entweder bin ich blind oder doof.

Ich habe eine Prozedur die ein Verzeichnis mit Dateien durchläuft.
Das alles geht über TWin32FindData.

Nun wird mir bei einer 15,6 GB großen ZIP-Datei mit folgender Zeile 3,69 GB ausgegeben:

Delphi-Quellcode:

Groesse := (wfd.nFileSizeHigh * (MAXDWORD)) + wfd.nFileSizeLow;

Ist die Berechnung falsch?

[jbg]

Zitat:

Zitat von Jim Carrey (Beitrag 1349734)

Delphi-Quellcode:

Groesse := (wfd.nFileSizeHigh * (MAXDWORD)) + wfd.nFileSizeLow;

Ist die Berechnung falsch?

MAXDWORD ist ums eins zu klein und du bekommst auch noch einen Integer-Overflow da der Compiler nicht automatisch nach Int64 konvertiert.


Probiere es mal so:

Delphi-Quellcode:

var
  Groesse: Int64;

Groesse := Int64(wfd.nFileSizeHigh) shl 32 + wfd.nFileSizeLow;

[Jim Carrey]

Resultat: 15,69 GB - exakt.
Ich muss mir deine Lösung gleich mal in Ruhe angucken, damit ich sie auch verstehe.
Habe eben auch schon gelesen, dass es ein Limit von 4 GB irgendwo gibt.

Ich bedanke mich! Und ich gucke mir das gleich mal in Ruhe an.

[himitsu]

Zitat:

Zitat von Jim Carrey (Beitrag 1349734)

Delphi-Quellcode:

Groesse := (wfd.nFileSizeHigh * (MAXDWORD)) + wfd.nFileSizeLow;

Ist die Berechnung falsch?

JA

Delphi erweitert Typen automatisch nur auf 32 Bit, solange alle Typen maximal 32 Bit sind, mit dem selben Vorzeichen (SIGNED- und UNSIGNED-Typen)

Das macht der Compiler aus deinem Code:

Delphi-Quellcode:

Groesse := (LongWord(wfd.nFileSizeHigh) * LongWord(MAXDWORD)) + LongWord(wfd.nFileSizeLow);

Aber du willst ja eher

Delphi-Quellcode:

Groesse := (UInt64(wfd.nFileSizeHigh) * LongWord(MAXDWORD)) + LongWord(wfd.nFileSizeLow);

[edit] Natürlich auch das MAXDWORD+1 beachten ... siehe Vorredner

Oder besser noch

Delphi-Quellcode:

Groesse := (UInt64(wfd.nFileSizeHigh) shl 32) or wfd.nFileSizeLow;

Int64 oder UInt64, jenachdem wie

Delphi-Quellcode:

Groesse

deklariert ist (aber es sollte natürlich eher UInt64 sein)

PS: In deinem Fall hättest du den Typ-Fehler sofort gefunden, wenn du in den Projektoptionen einmal die Bereichsprüfung Überlaufprüfung aktiviert hättest.

PS2: Man könnte auch Casten, statt rechnen/schieben -> Int64Rec oder LARGE_INTEGER

[Jim Carrey]

Stupide Frage :P
Ist es sinnvoll da wo es sinnvoll ist, UInt64 statt Int64 zu verwenden?
Habe immer ein bisschen Angst, dass wenn ich UInt64 verwende unvorhergesehen trotzdem ein Wert <0 rauskommt und es dann zu einer AV oder Ähnlichem kommt (da UInt64 deklariert statt Int64).

[Luckie]

Wenn eine Dateigröße negativ ist, dann stimmt an einer ganz anderen Stelle schon was nicht. :?

[Jim Carrey]

Das bedeutet, das kann eigentlich gar nicht passieren? Würde mich auch schwer wundern.

[himitsu]

Zitat:

Zitat von Jim Carrey (Beitrag 1349743)

Das bedeutet, das kann eigentlich gar nicht passieren? Würde mich auch schwer wundern.

UInt64 ist halt "richtiger", aber so lange die Dateien kleiner als 9,22 ExaByte sind, gibt es selten Probleme.

Aber früher gab es auch keine Probleme, wenn jemand Pointer zu Integer castete, dazumal damals schon Cardinal richtiger gewesen wäre, aber es jetzt ja eigentlich NativeUInt wäre.

[jbg]

Zitat:

Zitat von himitsu (Beitrag 1349746)

UInt64 ist halt "richtiger"

Ich habe wohl zu viel Java programmiert, da gibt es keine unsigned Datentypen.

Und durch die ganzen Cardinals im VirtualTreeView war man nur am Rum-casten, damit der Compiler keine "unsigned mit signed Integer-Vergleich" Warnungen ausspuckte. Deswegen verzichte ich normalerweise auf UInt64/Cardinal, wenn es sich nicht um interne Daten handelt, die von außen (andere Entwickler) zugegriffen werden, oder wenn ich am Schluss einen DWORD oder UINT WinAPI Parameter habe.

[Jim Carrey]

Zitat:

9,22 ExaByte

Da komme ich ja gerade mal so mit hin :-D
Spaß bei Seite. Bevor ich irgendwo Dateien mit einer Gesamtgröße von 9,22 EB habe, brauche ich tausende Euros, um die Festplatte dafür zu kaufen.