TZipfile - ModifiedDateTime unter Linux und MAC richtig auslesen

[Harry Stahl]

Zitat von Uwe Raabe:

Wieso soll das ein Fehler von TZipFile sein? Das Feld ModifiedDateTime steht als UInt32 im ZipHeader. Das Problem ist die Umwandlung über FileDateToDateTime und das hat gar nichts mit TZipFile zu tun.

Da stimme ich Dir zu, Uwe, das war auch letztlich meine abschließende Schlussfolgerung in Beitrag #8.

Am Anfang sah es aber erstmal so aus, daher ja meine Frage und der Post des verwendeten Beispiels...

[Harry Stahl]

Zitat von Uwe Raabe:

Ich glaube auch nicht, dass hier die unterschiedlichen Längen eines Longint die Ursache sind. Vielmehr wird bei Unix die Anzahl der Sekunden seit 1. Januar 1970, 00:00 Uhr UTC in dem Wert gespeichert, während bei der MS-DOS Version die einzelnen Datums- und Zeitanteile als Bits abgelegt sind (siehe DosDateTimeToFileTime). Daraus wird klar, dass die Umwandlung eines MS-DOS Zeitstempels mit Unix-Methoden nicht das erwartete Ergebnis bringen kann.

Aber warum funktioniert FileTimeToDateTime dann unter Linux, wenn als Parameter ein LongInt verwendet wird (mein og. Beispiel mit Searchrec.time), aber nicht, wenn als Parameter ein UINT32 verwendet wird (wie hier in Modifieddate)?

[Uwe Raabe]

Zitat von Harry Stahl:

Aber warum funktioniert FileTimeToDateTime dann unter Linux, wenn als Parameter ein LongInt verwendet wird (mein og. Beispiel mit Searchrec.time)

Weil das Searchrec unter Linux das Datum und die Uhrzeit natürlich schon korrekt codiert enthält. Das kommt ja vom Betriebssystem und nicht aus der ZIP-Datei.

Zitat von TurboMagic:

.
Die frage ist nur, ob so eine Umwandlungsroutine nicht irgendwo mitgeliefert werden sollte?

Interessanterweise wird sie das in System.Zip bereits - leider nur private:

Delphi-Quellcode:

function WinFileDateToDateTime(FileDate: UInt32; out DateTime: TDateTime): Boolean;

[TurboMagic]

Zitat von Uwe Raabe:

Zitat von Harry Stahl:

Aber warum funktioniert FileTimeToDateTime dann unter Linux, wenn als Parameter ein LongInt verwendet wird (mein og. Beispiel mit Searchrec.time)

Weil das Searchrec unter Linux das Datum und die Uhrzeit natürlich schon korrekt codiert enthält. Das kommt ja vom Betriebssystem und nicht aus der ZIP-Datei.

Zitat von TurboMagic:

.
Die frage ist nur, ob so eine Umwandlungsroutine nicht irgendwo mitgeliefert werden sollte?

Interessanterweise wird sie das in System.Zip bereits - leider nur private:

Delphi-Quellcode:

function WinFileDateToDateTime(FileDate: UInt32; out DateTime: TDateTime): Boolean;

Na dann ist ja klar, was man sich wünschen sollte
Lasst es public werden...

[Harry Stahl]

Zitat von Uwe Raabe:

Zitat von Harry Stahl:

Aber warum funktioniert FileTimeToDateTime dann unter Linux, wenn als Parameter ein LongInt verwendet wird (mein og. Beispiel mit Searchrec.time)

Weil das Searchrec unter Linux das Datum und die Uhrzeit natürlich schon korrekt codiert enthält. Das kommt ja vom Betriebssystem und nicht aus der ZIP-Datei.

Wobei das "Zipfile.FileInfo[c].ModifiedDateTime" auf allen Plattformen denselben Wert enthält.

FileDateToDateTime, das als Parameter ein LongInt erwartet - macht daher unter Windows den richtigen Wert draus, da UINT32 auch unter Windows ein 4 Byte Wert ist, wie eben auch LongInt.

Unter Linux 64 Bit ist LongInt aber ein 8 Byte Wert, daher kann man letztlich nicht den UINT32-4-Byte Wert an eine Funktion übergeben, die unter Linux (anders als unter Windows) einen 8 Byte-Wert erwartet.

"searchrec.Time" ist unter Windows ein Integer (ist unter Windows übrigens als "platform deprecated" gekennzeichnet), unter posix als time_t platform und als LongInt deklariert. Da Integer und LongInt unter Windows beides mal 4 Byte haben, macht es nichts, dass der Paramenter von FileTimeToDateTime "LongInt" ist. Aber unter Linux-64 ist LongInt eben 8 Byte. Searchrec hat es mit der oben beschriebenen Weise dann für Linux angepasst, so dass die Werte für "time" stimmen. UINT32 bleibt aber immer 4 Byte.

Die Werte in Zipfile.FileInfo[c].ModifiedDateTime sind daher auch nicht falsch, sondern müssen eben je nach Plattform nur anders ausgewertet werden. Aber da muss man erst mal drauf kommen...

Ich habe daher auch mal den Titel des Threads geändert in "...richtig auslesen", damit man hier nicht einen falschen Eindruck bekommt.

[Uwe Raabe]

Zitat von Harry Stahl:

FileDateToDateTime, das als Parameter ein LongInt erwartet - macht daher unter Windows den richtigen Wert draus, da UINT32 auch unter Windows ein 4 Byte Wert ist, wie eben auch LongInt.

Unter Linux 64 Bit ist LongInt aber ein 8 Byte Wert, daher kann man letztlich nicht den UINT32-4-Byte Wert an eine Funktion übergeben, die unter Linux (anders als unter Windows) einen 8 Byte-Wert erwartet.

Das hat nichts mit 4 oder 8 Byte zu tun. Das MS-DOS FileDate, das bei Zip verwendet wird, ist ein 32Bit Wert mit folgendem Inhalt:

Code:

 Bits
 0- 4  Sekunden div 2
 5-10  Minuten (0–59)
11-15  Stunden (0–23)
16-20  Tag (1–31)
21-24  Monat (1 = Januar, 2 = Februar, ...)
25-31  Jahr - 1980

Bei Unix ist es entweder ein 32- oder 64-Bit Wert, aber in jedem Fall stehen da die Anzahl der Sekunden seit dem (oder bis zum wenn negativ) 1. Januar 1970, 00:00 Uhr. Solange diese Anzahl in 32-Bit dargestellt werden kann, spielt es keine Rolle ob es ein 32-Bit oder 64-Bit System ist. Es ist immer eine Anzahl von Sekunden. Beim MS-DOS (und somit auch Zip-)Format ist das aber völlig anders.

Zitat von Harry Stahl:

Die Werte in Zipfile.FileInfo[c].ModifiedDateTime sind daher auch nicht falsch, sondern müssen eben je nach Plattform nur anders ausgewertet werden.

Eben nicht! Sie müssen auf allen Plattformen gleich ausgewertet werden. Deswegen geht FileDateToDateTime auch nicht, da dieses die Auswertung je nach Plattform unterschiedlich macht (siehe das IFDEF).

[himitsu]

Und LONG als 8 Byte (was ja eigentlich LONG LONG wäre) ... das kann so doch auch nicht ganz richtig sein?

[Harry Stahl]

Zitat von Uwe Raabe:

Zitat von Harry Stahl:

FileDateToDateTime, das als Parameter ein LongInt erwartet - macht daher unter Windows den richtigen Wert draus, da UINT32 auch unter Windows ein 4 Byte Wert ist, wie eben auch LongInt.

Unter Linux 64 Bit ist LongInt aber ein 8 Byte Wert, daher kann man letztlich nicht den UINT32-4-Byte Wert an eine Funktion übergeben, die unter Linux (anders als unter Windows) einen 8 Byte-Wert erwartet.

Das hat nichts mit 4 oder 8 Byte zu tun. Das MS-DOS FileDate, das bei Zip verwendet wird, ist ein 32Bit Wert mit folgendem Inhalt:

Code:

 Bits
 0- 4  Sekunden div 2
 5-10  Minuten (0–59)
11-15  Stunden (0–23)
16-20  Tag (1–31)
21-24  Monat (1 = Januar, 2 = Februar, ...)
25-31  Jahr - 1980

Bei Unix ist es entweder ein 32- oder 64-Bit Wert, aber in jedem Fall stehen da die Anzahl der Sekunden seit dem (oder bis zum wenn negativ) 1. Januar 1970, 00:00 Uhr. Solange diese Anzahl in 32-Bit dargestellt werden kann, spielt es keine Rolle ob es ein 32-Bit oder 64-Bit System ist. Es ist immer eine Anzahl von Sekunden. Beim MS-DOS (und somit auch Zip-)Format ist das aber völlig anders.

Zitat von Harry Stahl:

Die Werte in Zipfile.FileInfo[c].ModifiedDateTime sind daher auch nicht falsch, sondern müssen eben je nach Plattform nur anders ausgewertet werden.

Eben nicht! Sie müssen auf allen Plattformen gleich ausgewertet werden. Deswegen geht FileDateToDateTime auch nicht, da dieses die Auswertung je nach Plattform unterschiedlich macht (siehe das IFDEF).

1. Ich habe den Eindruck wir meinen wohl ziemlich ähnliches, reden aber ein wenig aneinander vorbei. Klar, ein 32-Bitiger Wert kann in 64-Bit enthalten sein und insofern auch ausgewertet werden. Manchmal gibt es aber Fälle, wo der ganze 64-Bit Wert, z.B. für eine Berechnung verwendet wird und wenn der nicht genullt ist (weil z.B. ein Zeiger auf einen Speicherbereich), dann kann es in einer solchen Konstellation zu Problemen führen (der Fall ist hier aber wohl nicht relevant).

2. Mit "anders auswerten" meinte ich ja auch, dass FileDateToDateTime nicht (auf allen Plattformen) verwendet werden kann...

[Uwe Raabe]

Kurz gesagt, auf 32-Bit Posix (Longint = 4 Byte) würde es mit FileDateToDateTime trotzdem nicht funktionieren.