- Community Home
- >
- Servers and Operating Systems
- >
- Operating Systems
- >
- Operating System - OpenVMS
- >
- Re: VMS Unzip doesn't adjust for GMT
Categories
Company
Local Language
Forums
Discussions
Forums
- Data Protection and Retention
- Entry Storage Systems
- Legacy
- Midrange and Enterprise Storage
- Storage Networking
- HPE Nimble Storage
Discussions
Discussions
Discussions
Forums
Forums
Discussions
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
- BladeSystem Infrastructure and Application Solutions
- Appliance Servers
- Alpha Servers
- BackOffice Products
- Internet Products
- HPE 9000 and HPE e3000 Servers
- Networking
- Netservers
- Secure OS Software for Linux
- Server Management (Insight Manager 7)
- Windows Server 2003
- Operating System - Tru64 Unix
- ProLiant Deployment and Provisioning
- Linux-Based Community / Regional
- Microsoft System Center Integration
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Community
Resources
Forums
Blogs
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО11-18-2009 12:35 PM
тАО11-18-2009 12:35 PM
VMS Unzip doesn't adjust for GMT
We package our sources files in Europe for VMS using zip on a Unix system, transfer the file, then build our application in the US. Unzipping the source files in the US doesn't adjust the file timestamps for GMT causing Gnu make to complain about some files with future timestamps, resulting in build failure.
Please fix, or advise on how to fix. This is a high priority issue for our company.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО11-18-2009 12:54 PM
тАО11-18-2009 12:54 PM
Re: VMS Unzip doesn't adjust for GMT
is. (Pre V7.0?)
Output from "unzip -v"?
No bets, but I'd guess that it all works
where the underlying C run-time support
exists.
Around here, for example:
alp $ unzip -v
UnZip 5.52 of 28 February 2005, 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/infozip/ ;
see ftp://ftp.info-zip.org/pub/infozip/UnZip.html for other sites.
Compiled with DEC C V6.5-001 for OpenVMS (V7.3-1 Alpha) on May 18 2005.
UnZip special compilation options:
COPYRIGHT_CLEAN (PKZIP 0.9x unreducing method not supported)
TIMESTAMP
USE_EF_UT_TIME
USE_UNSHRINK (PKZIP/Zip 1.x unshrinking method supported)
USE_DEFLATE64 (PKZIP 4.x Deflate64(tm) supported)
[decryption, version 2.9 of 05 May 2000]
[...]
alp $ unzip6l -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/infozip/ ;
see ftp://ftp.info-zip.org/pub/infozip/UnZip.html for other sites.
Compiled with DEC C V7.3-009 for OpenVMS (V7.3-2 Alpha) on Apr 29 2009.
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 permit)
TIMESTAMP
USE_EF_UT_TIME
USE_UNSHRINK (PKZIP/Zip 1.x unshrinking method supported)
USE_DEFLATE64 (PKZIP 4.x Deflate64(tm) supported)
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.5, 10-Dec-2007)
[decryption, version 2.11 of 05 Jan 2007]
[...]
Note the "USE_EF_UT_TIME" in both. If you
don't see that, then you may be doomed (or
have some solvable problem, depending).
> [...] using zip on a Unix system [...]
Output fron "zip -v" there might be
informative, too. Some fossil version might
not be storing the "UT" extra fields. (Look
for "USE_EF_UT_TIME" there, too.) As I
recall, the original Zip archive format
stored (DOS) local time. More than that is a
bonus, and, while very commonly available,
it's not universal.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО11-18-2009 01:00 PM
тАО11-18-2009 01:00 PM
Re: VMS Unzip doesn't adjust for GMT
Output from unzip -v is
$ unzip552 -v
UnZip 5.52 of 28 February 2005, 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/infozip/ ;
see ftp://ftp.info-zip.org/pub/infozip/UnZip.html for other sites.
Compiled with DEC C V7.1-005 for VMS (XALQ-T3Z VAX) on Feb 28 2005.
UnZip special compilation options:
COPYRIGHT_CLEAN (PKZIP 0.9x unreducing method not supported)
TIMESTAMP
USE_EF_UT_TIME
USE_UNSHRINK (PKZIP/Zip 1.x unshrinking method supported)
USE_DEFLATE64 (PKZIP 4.x Deflate64(tm) supported)
[decryption, version 2.9 of 05 May 2000]
UnZip and ZipInfo environment options:
UNZIP_OPTS: [none]
UNZIPOPT: [none]
ZIPINFO_OPTS: [none]
ZIPINFOOPT: [none]
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО11-18-2009 03:09 PM
тАО11-18-2009 03:09 PM
Re: VMS Unzip doesn't adjust for GMT
$ zn = "zipname.zip"
$ dt =f$file(zn,"CDT")
$ dt = f$element(0," ",dt) + ":" + f$element(1," ",dt)
$ set file/attr=credate='dt'/moddate='dt' *.*;*
There's also the possibility that the system time setting on the OpenVMS box is messed up, too. That's unfortunately an easy state to get into, given the implementation. To check that, post:
SHOW LOGICAL SYS$TIMEZONE*
Also, post a unzip -v from the source Unix box.
Post up a small zip reproducer, too. Show a timestamp, zip some non-sensitive text files, and post (attach) the zip here.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО11-18-2009 04:19 PM
тАО11-18-2009 04:19 PM
Re: VMS Unzip doesn't adjust for GMT
> box.
"zip -v".
> Post up a small zip reproducer, too. [...]
Or for even more fun, use "unzip -Zv" to
analyze the archive. For example, using an
UnZip 6.0 kit (created in Germany, I
believe), selecting a typical file:
ALP $ unzip6l -Zv UNZIP60.ZIP unzip60/ttyio.h
Archive: ALP$DKA0:[UTILITY.SOURCE.ZIP]UNZIP60.ZIP;1
[...]
Central directory entry #42:
---------------------------
unzip60/ttyio.h
offset of local header from start of archive: 291515
(00000000000472BBh) bytes
file system or operating system of origin: MS-DOS, OS/2 or NT FAT
version of encoding software: 3.0
minimum file system compatibility required: MS-DOS, OS/2 or NT FAT
minimum software version required to extract: 2.0
compression method: deflated
compression sub-type (deflation): maximum
file security status: not encrypted
extended local header: no
file last modified on (DOS date/time): 2004 Sep 9 00:03:46
file last modified on (UT extra field modtime): 2004 Sep 8 17:03:46 local
file last modified on (UT extra field modtime): 2004 Sep 8 22:03:46 UTC
32-bit CRC value (hex): c6a5f5e0
compressed size: 1789 bytes
uncompressed size: 5348 bytes
length of filename: 15 characters
length of extra field: 9 bytes
length of file comment: 0 characters
disk number on which file begins: disk 1
apparent file type: text
non-MSDOS external file attributes: 000000 hex
MS-DOS file attributes (20 hex): arc
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/access/creation times.
[...]
That "file last modified" stuff tells the
story. Apparently, the local time was
UTC+2:00. I'll admit that I don't understand
why it gets a five-hour difference between
UTC and local, when I should be on standard
time in CST6CDT, so UTC-6:00. Whatever the
cause, it seems not to be VMS-specific, as I
see the same things on an HP_UX system (where
"ls -l" is less useful for revealing the time
on a file that old.) In any case, that file
was restored on my VMS system with date-time
"8-SEP-2004 17:03:46.00".
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО11-18-2009 06:33 PM
тАО11-18-2009 06:33 PM
Re: VMS Unzip doesn't adjust for GMT
> why [...]
Of course, that was a summer file, so I was
in CDT at its date-time. It's a six-hour
difference for a winter file:
ALP $ unzip6l -Zv UNZIP60.ZIP unzip60/unzip.h
Archive: ALP$DKA0:[UTILITY.SOURCE.ZIP]UNZIP60.ZIP;1
[...]
Central directory entry #47:
---------------------------
unzip60/unzip.h
offset of local header from start of archive: 322232
(000000000004EAB8h) bytes
file system or operating system of origin: MS-DOS, OS/2 or NT FAT
version of encoding software: 3.1
minimum file system compatibility required: MS-DOS, OS/2 or NT FAT
minimum software version required to extract: 2.0
compression method: deflated
compression sub-type (deflation): maximum
file security status: not encrypted
extended local header: no
file last modified on (DOS date/time): 2009 Feb 15 19:12:54
file last modified on (UT extra field modtime): 2009 Feb 15 12:12:54 local
file last modified on (UT extra field modtime): 2009 Feb 15 18:12:54 UTC
32-bit CRC value (hex): 36eea94f
compressed size: 8010 bytes
uncompressed size: 26144 bytes
length of filename: 15 characters
length of extra field: 9 bytes
length of file comment: 0 characters
disk number on which file begins: disk 1
apparent file type: text
non-MSDOS external file attributes: 000000 hex
MS-DOS file attributes (20 hex): arc
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/access/creation times.
[...]
Hence:
ALP $ dire /date unzip.h
Directory ALP$DKA0:[UTILITY.SOURCE.ZIP.UNZIP60]
UNZIP.H;1 15-FEB-2009 12:12:54.00
Total of 1 file.
But my point remains that if the
(unspecified) Zip program on the
(unspecified) "Unix system" stores only the
(local) "DOS date/time" and not the UT extra
fields, then UnZip on the VMS system won't
have the info it needs to do the job
correctly.
Any reasonably recent Info-ZIP Zip program on
a UNIX(-like) system should be built with
USE_EF_UT_TIME. For example:
dyi # /usr/local/bin/zip232 -v
Copyright (c) 1990-2006 Info-ZIP - Type 'zip "-L"' for software license.
This is Zip 2.32 (June 19th 2006), by Info-ZIP.
[...]
Compiled with HP C version A.06.12 for Unix (HP-UX) on Jan 24 2008.
Zip special compilation options:
USE_EF_UT_TIME
[encryption, version 2.91 of 31 May 2006]
[...]
(Any Zip before 2.31 is before my time, hence
not my fault.)
> Compiled with DEC C V7.1-005 for VMS (XALQ-T3Z VAX) on Feb 28 2005.
That's a little scary, but that "VAX" should
be "IA64" in UnZip 6.0. Just one of the many
reasons to use the newer version.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО11-19-2009 02:34 AM
тАО11-19-2009 02:34 AM
Re: VMS Unzip doesn't adjust for GMT
Copyright (c) 1990-2006 Info-ZIP - Type 'zip "-L"' for software license.
This is Zip 2.32 (June 19th 2006), by Info-ZIP.
Currently maintained by Onno van der Linden. Please send bug reports to
the authors 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/infozip,
as of above date; see http://www.info-zip.org/ for other sites.
Compiled with gcc 3.4.6 for Unix (Sun SPARC/Solaris) on Aug 29 2007.
Zip special compilation options:
USE_EF_UT_TIME
[encryption, version 2.91 of 31 May 2006]
Encryption notice:
The encryption code of this program is not copyrighted and is
put in the public domain. It was originally written in Europe
and, to the best of our knowledge, can be freely distributed
in both source and object forms from any country, including
the USA under License Exception TSU of the U.S. Export
Administration Regulations (section 740.13(e)) of 6 June 2002.
Zip environment options:
ZIP: [none]
ZIPOPT: [none]
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО11-19-2009 03:05 AM
тАО11-19-2009 03:05 AM
Re: VMS Unzip doesn't adjust for GMT
> [...]
> Zip special compilation options:
> USE_EF_UT_TIME
> [...]
It's not 3.0, but it should be good enough.
It'd still be subject to user intervention
(interference), by, say, "-X" ("eXclude
eXtra file attributes") on the Zip command
line, or some other too-clever operation
whose details lie beyond the limits of my
imagination. Need to see a test archive
and/or some "unzip -Zv" output to see if the
"UT" extra fields are in there or not (and
what's in them). The mystery is getting more
subtle.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО11-19-2009 08:41 PM
тАО11-19-2009 08:41 PM
Re: VMS Unzip doesn't adjust for GMT
$ unzip552 "-Zv" foo.zip "gcc-41-vms/gcc/config/ia64/ia64.h"
Archive: FOO.ZIP;1 35222371 bytes 4989 files
End-of-central-directory record:
-------------------------------
Actual offset of end-of-central-dir record: 35222349 (0219734Dh)
Expected offset of end-of-central-dir record: 35222349 (0219734Dh)
(based on the length of the central directory and its expected offset)
This zipfile constitutes the sole disk of a single-part archive; its
central directory contains 4989 entries. The central directory is 396529
(00060CF1h) bytes long, and its (expected) offset in bytes from the
beginning of the zipfile is 34825820 (0213665Ch).
There is no zipfile comment.
Central directory entry #664:
---------------------------
gcc-41-vms/gcc/config/ia64/ia64.h
offset of local header from start of archive: 2404705 (0024B161h) bytes
file system or operating system of origin: Unix
version of encoding software: 2.3
minimum file system compatibility required: MS-DOS, OS/2 or NT FAT
minimum software version required to extract: 2.0
compression method: deflated
compression sub-type (deflation): normal
file security status: not encrypted
extended local header: no
file last modified on (DOS date/time): 2009 Nov 19 03:18:26
32-bit CRC value (hex): a7ef4909
compressed size: 23398 bytes
uncompressed size: 80465 bytes
length of filename: 33 characters
length of extra field: 0 bytes
length of file comment: 0 characters
disk number on which file begins: disk 1
apparent file type: text
Unix file attributes (100664 octal): -rw-rw-r--
MS-DOS file attributes (00 hex): none
There is no file comment.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО11-19-2009 09:02 PM
тАО11-19-2009 09:02 PM
Re: VMS Unzip doesn't adjust for GMT
Yup. (And that's "it's".)
> what are they supposed to look like?
As shown above, in "unzip -Zv" output:
[...]
file last modified on (UT extra field modtime): 2009 Feb 15 12:12:54 local
file last modified on (UT extra field modtime): 2009 Feb 15 18:12:54 UTC
[...]
length of extra field: 9 bytes
[...]
The local extra field has UTC/GMT modification/access/creation times.
[...]
> length of extra field: 0 bytes
So, in your archive, no UT extra field (or
any other). The "zip -v" report which you
provided suggests that that Zip program can
employ them ("USE_EF_UT_TIME"), so, with no
evidence to the contrary, I'm still guessing
that a "-X" option on the Zip command (or in
the ZIP or ZIPOPT environment variable, or
somewhere) was the culprit. Or the archive
was actually created using some other (older)
Zip program. (Or some other sneaky reason
which is not leaping to mind.)