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

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

[download]

Replies are listed 'Best First'.
Re^15: Archive::Zip Modify Date Oddity
by pmqs (Friar) on Jan 16, 2017 at 22:31 UTC

    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?

[reply]

      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.

[reply]
Re^15: Archive::Zip Modify Date Oddity
by Anonymous Monk on Jan 16, 2017 at 08:00 UTC
[reply]

In Section Seekers of Perl Wisdom