Closed asylumcs closed 3 years ago
I recall wanting to come back to this. My memory is there was something about the formatting or encoding I just didn't want to do the day I was working on this is all.
Your package, if it were to include dates, is the only way I know that a Nim program could duplicate the operation of the zip
program on Linux. Python gets it right. And Nim gets it right with other libraries on Mac and Linux. But on Windows, Nim compiles that use the underlying libraries will either set it to the current date or to 1980-01-01. Only on WIndows. Your pure Nim solution would is the only hope. It's lines 338 and 339 of ziparchives.nim where it's currently 0. Looks like you started to include dates based on getting that info from the file (source code lines 77, 78) but that is commented out now.
I have no workaround and I'm not smart enough with Nim yet to do a PR, so if you think you will be making changes to preserve the file date, I'd sure like to know about it. It is essential for our work that the dates be preserved. Please let me (us) know your intentions. Thanks for this code!
I do intent to correct this issue (and wrote Zippy in general to address a critical need I felt Nim had, as you've noted). Keep an eye on this issue or the notifications or however you prefer for a note when it has been addressed in a release.
Zippy should now store the correct last modified time on files when creating zip archives and also set files to have the correct last modified when extracting. This is included in releases 0.6.1+.
Zip files created with zippy (at least on Windows 64) do not preserve the date/time of the original files. Instead, everything is dated 1980-00-00 00:00.
Another nim package, zip/zipfles, does preserve time/dates but it doesn't work on Windows 64. I'd really like to use zippy. Is there a way?