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

SimpleZip is just a wrapper around IO::Compress::Zip. IO::Compress::Zip is a core library and also supports the extended timestamp.

Replies are listed 'Best First'.
Re^6: Archive::Zip Modify Date Oddity
by lhchin (Novice) on Jan 06, 2017 at 02:53 UTC
    use IO::Compress::Zip qw(zip $ZipError); my $zip = zip [$0] => 'test.zip', Name => 'test.txt', exTime => [$atime, $mtime, $ctime] or die;
    Well, it still does not retain the original modified date of the file, losing the seconds resolution. Not sure if this is correct, perhaps someone could share and prove that the original modified date can be retained.
    Keeping things simple, Perl shell execution Zip doesn't require much setting to retain the original modified date.

      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";
        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.
Re^6: Archive::Zip Modify Date Oddity
by lhchin (Novice) on Jan 11, 2017 at 00:00 UTC
    Thanks for the result, but this is what I am getting,
    first is the shell zip, which retained the timestamp.
    next is perl zip which timestamp became current.
    lastly is perl zip with extime which timestamp rounded down to even seconds.

    OS RHEL
    $ stat abc | grep Mod Modify: 2017-01-09 18:46:05.000000000 -0800 $ zip abc.zip abc adding: abc (stored 0%) $ unzip abc.zip Archive: abc.zip replace abc? [y]es, [n]o, [A]ll, [N]one, [r]ename: r new name: abc2 extracting: abc2 $ stat abc2 | grep Mod Modify: 2017-01-09 18:46:05.000000000 -0800 $ rm abc.zip $ perl -M'IO::Compress::Zip qw(zip)' -e ' zip "abc" => "abc.zip" ' $ unzip abc.zip Archive: abc.zip replace abc? [y]es, [n]o, [A]ll, [N]one, [r]ename: r new name: abc3 inflating: abc3 $ stat abc3 | grep Mod Modify: 2017-01-10 15:54:35.000000000 -0800 $ rm abc.zip $ perl -M'IO::Compress::Zip qw(zip)' -e ' zip "abc" => "abc.zip", exT +ime => [$atime, $mtime, $ctime] ' $ unzip abc.zip Archive: abc.zip replace abc? [y]es, [n]o, [A]ll, [N]one, [r]ename: r new name: abc4 inflating: abc4 $ stat abc4 | grep Mod Modify: 2017-01-09 18:46:04.000000000 -0800

      The third version you used (shown blow) will never work - that is telling IO:Compress::Zip to use the values for the variables $atime, $mtime and $ctime in the extended timestamp field in the zip file. Those variable have no value, so that will screw up the extended timestamp in the zip file.

      $ perl -M'IO::Compress::Zip qw(zip)' -e ' zip "abc" => "abc.zip", exT ime => [$atime, $mtime, $ctime] '

      Perhaps you are running an ancient version of IO::Compress::Zip that predates the change where extended timestamp support was added. What version do you get when you run this?

      $ perl -M'IO::Compress::Zip' -e 'print "$IO::Compress::Zip::VERSION\n" +' 2.061

      Also, if you have zipinfo installed, that can tell if the zip archive contains the extended timestamp. In the output below the lines "file last modified on (UT extra field modtime)" show that this archive does have the more accurate timestamp.

      $ perl -M'IO::Compress::Zip qw(zip)' -e ' zip "abc" => "abc.zip" $ zipinfo -v abc.zip Archive: abc.zip There is no zipfile comment. End-of-central-directory record: ------------------------------- Zip archive file size: 178 (00000000000000B2h) Actual end-cent-dir record offset: 156 (000000000000009Ch) Expected end-cent-dir record offset: 156 (000000000000009Ch) (based on the length of the central directory and its expected offse +t) This zipfile constitutes the sole disk of a single-part archive; its central directory contains 1 entry. The central directory is 73 (0000000000000049h) bytes long, and its (expected) offset in bytes from the beginning of the zipfile is 83 (0000000000000053h). Central directory entry #1: --------------------------- abc offset of local header from start of archive: 0 (0000000000000000h) +bytes file system or operating system of origin: Unix version of encoding software: 2.0 minimum file system compatibility required: MS-DOS, OS/2 or NT F +AT minimum software version required to extract: 2.0 compression method: deflated compression sub-type (deflation): normal file security status: not encrypted extended local header: yes file last modified on (DOS date/time): 2017 Jan 11 10:53:06 file last modified on (UT extra field modtime): 2017 Jan 11 10:53:07 + local file last modified on (UT extra field modtime): 2017 Jan 11 10:53:07 + UTC 32-bit CRC value (hex): 4788814e compressed size: 6 bytes uncompressed size: 4 bytes length of filename: 3 characters length of extra field: 24 bytes length of file comment: 0 characters disk number on which file begins: disk 1 apparent file type: text Unix file attributes (100644 octal): -rw-r--r-- MS-DOS file attributes (00 hex): none The central-directory extra field contains: - A subfield with ID 0x5455 (universal time) and 5 data bytes. The local extra field has UTC/GMT modification time. - A subfield with ID 0x7875 (Unix UID/GID (any size)) and 11 data by +tes: 01 04 5b 24 00 00 04 08 52 00 00. There is no file comment.
        Thank you for explaining and your patience, it is confirmed that the old version of Perl Lib is causing this.
        $ perl -M'IO::Compress::Zip' -e 'print "$IO::Compress::Zip::VERSION\n" +' 2.021 $ /usr/local/inventory/bin/perl -M'IO::Compress::Zip' -e 'print "$IO:: +Compress::Zip::VERSION\n"' 2.060 $ stat abc | grep Mod Modify: 2017-01-16 16:39:31.944512798 -0800 $ /usr/local/inventory/bin/perl -M'IO::Compress::Zip qw(zip)' -e ' zip + "abc" => "abc.zip" ' $ unzip abc.zip Archive: abc.zip replace abc? [y]es, [n]o, [A]ll, [N]one, [r]ename: r new name: abc2 inflating: abc2 $ stat abc2 | grep Mod Modify: 2017-01-16 16:39:31.000000000 -0800