Menu
▾
▴
#6 (Partial) Patch for zipnote 2.32 to change timestamps
Back in late July, I made a patch which enables zipnote 2.32 to change timestamps of zip entries. (Why? Fedora's build process unpacks and repacks jars just to change their timestamps. I'd like to change that.) Instead of editing the comment attached to each entry within a zip, zipnote -t edits the timestamp.
You use it like this:
> zipnote -t '2022-11-11 13:13:13' b.zip
> zipnote -t '2001-07-25' a.zip
I realise now that zip 2.32 was succeeded by 3.0 in early July. I think the http://infozip.sourceforge.net/ homepage fooled me - even now, it still says zip 2.32 is the latest!
The other problem is that there are many different possible (optional) timestamps inside zip files. My patch changes the basic timestamp z->tim, which I think is the original DOS timestamp from the earliest versions of the Zip format ("last mod file time"/"date" from appnote.iz).
It looks as jar files created by Java's jar command use the DOS timestamp and nothing else, but most zip implementations, including Info-Zip, probably include whatever timestamps are native to the host system.
Rather than try to handle every time-related optional field ever invented for Zip files (eg QDOS), a reasonable solution might be to remove any optional attributes which are known to contain timestamps. Removing all unknown attributes might be safer, but it's probably a bit too extreme!
I don't really know what I'm doing well enough to tackle that, but I thought I'd send in my patch in case it can be used.
Sean.
Patch to add -t option to zipnote for setting timestamps
Quick attempt at porting timestamp patch to zip-3.0
File Added: zip-3.0-timestamp.patch
I've had a go at porting my patch to the zip 3.0 sources. I guarantee only that it compiled on my system! I haven't had time to test it at all, but I thought I'd save someone from trying to get the patch to work with 3.0.
Thanks Sean. We need to give it some thought, but it seems useful to be able to set timestamps on some or all archive entries, more or less how some or all entries can be deleted with -d. I'm not sure -t is the best option for that, as -t and -tt are currently used to select files or entries with specific dates.
If it makes sense to add this change, the change could make it in to Zip 3.1a, the first public beta to be posted for the next update of Zip 3.0. That may go out in a week, assuming there's time to get it ready for public posting.
Another thing we haven't looked at is being able to specify time. Currently Zip only accepts dates without times. This seems a good addition though, but more thought on that is needed also.
I likely don't know every date field in Zip, but I believe there's only two places that the date needs to be updated, and that's the standard date field you noted and the UTC extra field. Probably that would be enough for now. If the first is updated in the right place, the second might automatically get updated. Not sure about QDOS though.
As for the patch, haven't looked yet but plan to start there when working the change. Feel free to provide additional thoughts or suggestions.
Shell script which helps to test whether two zips set to the same timestamp are truly identical
Hi Gordon.
You're right about setting timestamps individually, of course. I didn't tackle that partly because I don't have a need for it, but mainly because my C is not up to it. Someone who knows what they are doing would probably modify the zip command, not zipnote. I just went for zipnote because I knew it was already iterating through all the zip entries to visit the comments!
I just tried running my patched zipnote 3.0 and got a crash ("double free or corruption"), so it looks as if I missed something in my quick port. But the 2.32 patch definitely works, within its limitations. So hopefully the problem is small. I don't think I free() any memory, so I guess I've corrupted something.
In other bad news, it doesn't look as if the UTC field /is/ being updated automatically, unfortunately. I just put together a quick test, attached as testtimeset.sh, which builds a jar or zip from scratch, updates the timestamps, then generates a checksum.
If you run testzipnote.sh twice, you get the same checksum, which means the patch is working for jar files.
But if you run "testzipnote.sh -zip" to create ab.zip instead of ab.jar, the checksums at the end are different each time. (And if you "unzip -l ab.zip", the listed timestamps haven't changed.) Unzip -l must be listing another timestamp, one I haven't touched. And of course because that timestamp is different for each run, the checksums are different.
Hope some of that helps!
Sean.
File Added: testtimeset.sh
OK, it's on the TODO list for Zip 3.1 (to look at handling times) and ZipNote 3.1 (to allow changing timestamps). They probably won't make the Zip 3.1a beta, but the items were added to TODO and should make a later beta. In fact they're being looked at now for Zip 3.1b. It may make sense to allow Zip to also update timestamps and that's been added to the list, but there's already a lot on the TODO list and the goal is to get Zip 3.1 released later this year, which doesn't give much time for everything. Would appreciate help testing once we got something.