in reply to Re^12: Archive::Zip Modify Date Oddity
in thread Archive::Zip Modify Date Oddity

Output from zipinfo & zipdetails looks fine. You seem to have an identical version of unzip, so I'm struggling to explain why we don't get exactly the same bahavior when we unzip abc.zip.

Here are a couple of tests to try.

Can you try creating the zip file like this and see if the mod time is correct when you unzip it.

perl -M'IO::Compress::Zip qw(zip)' -e ' zip "abc" => "abc.zip", Stream + => 0 '

Also, try creating the zip file using the zip exe and see what the mod time looks like when unzipped.

zip abc.zip abc

Replies are listed 'Best First'.
Re^14: Archive::Zip Modify Date Oddity
by hippo (Archbishop) on Jan 11, 2017 at 16:14 UTC

    Even with either of those it's still a 2-second resolution:

    $ perl -M'IO::Compress::Zip qw(zip)' -e ' zip "abc" => "abc2.zip", Str +eam => 0 ' $ cd out $ rm abc $ unzip ../abc2.zip Archive: ../abc2.zip inflating: abc $ stat abc | grep Mod Modify: 2017-01-11 09:47:50.000000000 +0000 $ rm abc $ cd .. $ zip abc3.zip abc adding: abc (stored 0%) $ cd out $ unzip ../abc3.zip Archive: ../abc3.zip extracting: abc $ stat abc | grep Mod Modify: 2017-01-11 09:47:52.000000000 +0000

      The key observation is what you got when you created the archive with the standard "zip" command. That seems to imply that your unzip doesn't support the extended time.

      I see Slackware has been mentioned as a possible place where unzip may not be operating as expected. Is that the case for you?

        No, my tests were on Fedora (v22, now past EOL). However, I have just copied the same abc.zip from the Fedora box to a CentOS 7 box and when unzipped there it does instead have the correct timestamp of 09:47:51.

        So (as you, I and our anonymous brother suspected) it is indeed a problem with the unzip executable - in my case the version on the Fedora machine.