NTFS-Timestamps bei Unzip: Sommer-/Winterzeit-Problem

[SIGSEGV]

Hallo,

ich bin nicht sicher, ob das tatsächlich ein Bug im TC ist, weil Google einige Diskussionen dazu findet, deshalb erstmal hier die Beschreibung des Problems:

- Ich erstelle heute (Sommerzeit, CEST) ein ZIP mit einem anderen Tool, in das ein File gepackt wird, dass bei Winterzeit (CET) erstellt wurde, z.B. 01.01.2008 01:00 Uhr. NTFS zeigt den Zeitstempel der Datei heute (Sommerzeit) als 02:00 Uhr an
- Der Zeitstempel des "ZipEntry" wird auf UTC gesetzt, also 01.01.2008 00:00 Uhr
- Beim Entpacken dieses ZIPs mit TC wird der Timestamp der Datei dann zwar um 1 Stunde von UTC auf CET erhöht, aber nicht um "die zweite" von CET auf CEST

=> NTFS zeigt den Zeitstempel jetzt mit 01.01.2008 01:00 Uhr an
=> Bei Winterzeit wäre das 01.01.2008 00:00 Uhr
=> UTC wäre jetzt 31.12.2007 23:00 Uhr

Wenn ich also ein bei Winterzeit erstelltes File an einem Zeitpunkt in der Sommerzeit mit einem anderen Tool zippe und mit TC wieder entpacke, verschiebt sich der Zeitstempel jedesmal um 1 Stunde, im schlechten Fall ändert sich auch das Datum.

Ist das bewusst so implementiert oder tatsächlich ein Bug?

Werden die Timestamps in ZIPs immer als UTC interpretiert und je nach Sommerzeit/Winterzeit angezeigt? Oder ist evtl. genau das ZIP-Archiv das Problem, weil das ja eigentlich kein NTFS-Dateisystem ist?

Viele Grüße,
SIGSEGV

[ghisler(Author)]

Ja, das ZIP-Archiv ist das Problem: Es speichert wie FAT(32) die Dateien in Lokalzeit, nicht in UTC. Der Zeitstempel bei FAT32-Dateien und gepackten Dateien bleibt bei der Sommerzeitänderung also gleich, der auf NTFS-Laufwerken ändert sich dagegen um 1 Stunde.

[SIGSEGV]

Hmm, ist das für ZIP irgendwo so spezifiziert, dass da nicht UTC verwendet wird?
Ich hab in meiner Java-Implementierung (relativ naiv), den Zeitstempel des "ZipEntry" auf das "lastModified" des jeweiligen Files gesetzt, und Java liefert das in UTC.

Demnach müsste ich an der Stelle dann prüfen, ob es sich um einen "Sommerzeitstempel" handelt und ggf. 3600000 von dem Wert abziehen... bzw. das ganze "richtig" anhand der aktiven Zeitzone und DST ermitteln.

Ich hab noch was dazu gefunden (darf aber die URL noch nicht posten):

PKZIP format derives from MS DOS days and hence uses only 16 bits for time and 16 bits for date. There is defined an extended time stamp in the revised PKZIP format, but Java does not use it.

... also entweder in Java die "extended timestamps" implementieren oder den Timestamp selber auf CEST umrechnen...

[SIGSEGV]

Könnte man das im TC evtl. als Option "Setze ZIP-Zeitstempel auf UTC" ähnlich der NTFS-Sommerzeitkorrektur für den Verzeichnisvergleich implementieren?

[SIGSEGV]

So langsam komm ich drauf... wurde da zwischen TC 6.56 und TC 7.03 was an der Anzeige der Timestamps geändert? Die beiden Versionen zeigen mir aktuell die Zeit der Dateien im ZIP mit jeweils 2:00 Unterschied an - daher wohl auch die Probleme, da ich mit den beiden Versionen auf unterschiedlichen Rechnern arbeite...

[ghisler(Author)]

Nein, eigentlich nicht, die beiden sollten dasselbe Datum anzeigen. Können Sie mir ein kleines (max 200k) Testarchiv an support at ghisler punkt com schicken? Danke!

[SIGSEGV]

Ich hatte auf dem anderen Rechner (Win2K3) mittlerweile auch die Version 7.04 installiert. Nachdem ich die 6.56 jetzt nochmal parallel (allerdings unter XP) ausprobiert habe, kann ich das nicht mehr nachvollziehen.

Kann das Verhalten sich evtl. zwischen WindowsXP (SP3) und Windows Server 2003 (SP2) unterscheiden? Der Server ist leider gerade "down"... deshalb kann ich das aktuell nur auf XP testen.

[ghisler(Author)]

Kann ich mir nicht vorstellen - wohl eher an der speziellen ZIP-Datei, die enthielt möglicherweise das Datum im Unix-Format o.ä.