Date stamps in ZIP archives
Steffen Huber (91) 1945 posts |
Hi, I recently did some experiments to decode the ZIP extra fields written by (e.g.) SparkFS to identify RISC OS filetype information. All part of my work to build some Java software to support typical cross-platform use cases. The extra field (if it exists) contains load/exec (so usually filetype and date stamp) words. I noticed quite a range of differences between the plain ZIP entry date stamp and the extra field RISC OS date stamp. Some of them can be explained by millisecond vs. centisecond, local time vs. UTC, FAT-up-to-2-second-difference. But I also have one example of a difference of up to 7 days (the Sprites example archive I got from Jeffrey). AFAIK, ZIP uses similar-to-FAT timestamps and assumes local time and last modified time. Is there any known ZIP tool in RISC OS world, maybe in combination with a network filing system or a HostFS implementation, that would lead to such a strange behaviour, e.g. by getting (by accident?) creation time instead of last modified time? |
Steve Pampling (1551) 7932 posts |
I’ve commented in the past about the date stamps in the zip files (or the risc os vs. PC interpretation of the file date stamps.) Testing on a RPCEmu install times seem to be at odds. e.g. take the current Beta HardDisc zip file date stamped 00:47 on 2018-11-11 with internal file and directory stamps in that time period +/- a few minutes when viewed through SparkFS. 1 Let’s ignore the displayed time stamp of the archive as Windows likes to display the date/time you downloaded the file. |
Jeffrey Lee (213) 6046 posts |
I believe it’s a bug in the RISC OS port of the command-line zip tool, but I’m somewhat lacking in enthusiasm when it comes to trying to track down & fix the problem (mainly because the official info-zip project seems to have stagnated; the zip 3.1 release, which was due to include some major patches to the RISC OS version to bring it up to scratch, has been stuck in purgatory for years. And checking today, it seems like the info-zip website itself is half-dead. And of course there’s a restriction on the beta version which is that you’re not meant to distribute your own patched versions) I think the bug is present in the sources that are in the riscos.info autobuilder, which is based on 3.0 (with some significant patches – but I’m not sure how close those patches are to my 3.1 patches). I’m not sure if the bug is present in my patched 3.1 version. So if you’re up for a challenge, I can try and track down whatever my latest patches are meant to be and upload them somewhere. |