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

You don't need the exTime option - when you give the "zip" sub a filename (or list of filenames) it automatically gets the timestamps. 

use IO::Compress::Zip qw(zip $ZipError);

zip [$0] => 'test.zip', Name => 'test.txt'
 or die  "Cannot zip: $ZipError\n";

[download]

Replies are listed 'Best First'.
Re^8: Archive::Zip Modify Date Oddity
by lhchin (Novice) on Jan 09, 2017 at 04:03 UTC
    Could you kindly test by "stat" of the file you are zipping and after zipping, unzip the file and "stat" the modified date? It was definitely not retained for me.
[reply]

      Sure. Starting with a file where the seconds field of the modification time is an odd number. 

      $ stat abc | grep Mod
Modify: 2017-01-09 15:41:05.405778746 +0000

      [download]

      Now add that file into a zip archive. 

      $ perl -M'IO::Compress::Zip qw(zip)' -e ' zip "abc" => "abc.zip" '

      [download]

      unzip in a different directory 

      $ cd out
$ unzip ../abc.zip

      [download]

      And stat the uncompressed file 

      $ stat abc | grep Mod
Modify: 2017-01-09 15:41:05.000000000 +0000

      [download]
[reply]
[d/l]
[select]

        (++ for the sample). Interestingly, I see the other reported behaviour where the mtime is rounded down to even seconds:

        $ echo foo > abc
$ stat abc | grep Mod
Modify: 2017-01-11 09:47:51.022907652 +0000
$ perl -M'IO::Compress::Zip qw(zip)' -e ' zip "abc" => "abc.zip" '
$ mkdir out
$ cd out
$ unzip ../abc.zip
Archive:  ../abc.zip
  inflating: abc                     
$ stat abc | grep Mod
Modify: 2017-01-11 09:47:50.000000000 +0000

        [download]

        Versions are:

        • Perl 5.20.3
        • IO::Compress::Zip 2.068
        • FS: ext2
        • zlib 1.2.8-7

        And this from "unzip -v":

        UnZip 6.00 of 20 April 2009, by Info-ZIP.  Maintained by C. Spieler.  
+Send
bug reports using http://www.info-zip.org/zip-bug.html; see README for
+ details.

Latest sources and executables are at ftp://ftp.info-zip.org/pub/infoz
+ip/ ;
see ftp://ftp.info-zip.org/pub/infozip/UnZip.html for other sites.

Compiled with gcc 5.0.0 20150210 (Red Hat 5.0.0-0.11) for Unix (Linux 
+ELF) on Feb 11 2015.

UnZip special compilation options:
        COPYRIGHT_CLEAN (PKZIP 0.9x unreducing method not supported)
        SET_DIR_ATTRIB
        SYMLINKS (symbolic links supported, if RTL and file system per
+mit)
        TIMESTAMP
        UNIXBACKUP
        USE_EF_UT_TIME
        USE_UNSHRINK (PKZIP/Zip 1.x unshrinking method supported)
        USE_DEFLATE64 (PKZIP 4.x Deflate64(tm) supported)
        UNICODE_SUPPORT [wide-chars, char coding: UTF-8] (handle UTF-8
+ paths)
        MBCS-support (multibyte character support, MB_CUR_MAX = 6)
        LARGE_FILE_SUPPORT (large files over 2 GiB supported)
        ZIP64_SUPPORT (archives using Zip64 for large files supported)
        USE_BZIP2 (PKZIP 4.6+, using bzip2 lib version 1.0.6, 6-Sept-2
+010)
        VMS_TEXT_CONV
        [decryption, version 2.11 of 05 Jan 2007]

UnZip and ZipInfo environment options:
           UNZIP:  [none]
        UNZIPOPT:  [none]
         ZIPINFO:  [none]
      ZIPINFOOPT:  [none]

        [download]

        I'm wondering if maybe it's something in the unzip. Is there a simple way to query the entries in the zipfile to see what its contents are to the resolution of seconds? (I never use zip/unzip so this is all beyond my realm)

[reply]
[d/l]
[select]

In Section Seekers of Perl Wisdom