- 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-19-2009 09:31 PM
тАО11-19-2009 09:31 PM
Re: VMS Unzip doesn't adjust for GMT
find employs _multiple_ UTC extra fields.
For example, here's the old Zip which Sun
supplied with the OS:
sol# /usr/bin/zip -v
Copyright (C) 1990-1999 Info-ZIP
Type 'zip "-L"' for software license.
This is Zip 2.3 (November 29th 1999), by Info-ZIP.
Currently maintained by Onno van der Linden. Please send bug reports to
the authors at Zip-Bugs@lists.wku.edu; see README for details.
Latest sources and executables are at ftp://ftp.cdrom.com/pub/infozip, as of
above date; see http://www.cdrom.com/pub/infozip/Zip.html for other sites.
Compiled with cc for Unix (Sun Sparc/Solaris) on Jan 8 2005.
Zip special compilation options:
USE_EF_UT_TIME
Zip environment options:
ZIP: [none]
ZIPOPT: [none]
sol# /usr/bin/zip a_23.zip nil.c
adding: nil.c (deflated 29%)
sol# unzip6 -Zv a_23.zip
Archive: a_23.zip
There is no zipfile comment.
End-of-central-directory record:
-------------------------------
Zip archive file size: 285 (000000000000011Dh)
Actual end-cent-dir record offset: 263 (0000000000000107h)
Expected end-cent-dir record offset: 263 (0000000000000107h)
(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 1 entry.
The central directory is 64 (0000000000000040h) bytes long,
and its (expected) offset in bytes from the beginning of the zipfile
is 199 (00000000000000C7h).
Central directory entry #1:
---------------------------
nil.c
offset of local header from start of archive: 0
(0000000000000000h) 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 Aug 4 22:03:26
file last modified on (UT extra field modtime): 2009 Aug 4 22:03:25 local
file last modified on (UT extra field modtime): 2009 Aug 5 03:03:25 UTC
32-bit CRC value (hex): 8ab42934
compressed size: 143 bytes
uncompressed size: 200 bytes
length of filename: 5 characters
length of extra field: 13 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/access times.
- A subfield with ID 0x7855 (Unix UID/GID (16-bit)) and 0 data bytes.
There is no file comment.
It's all essentially similar with Zip 2.32
and Zip 3.0 (and between and beyond, all of
which which I built myself).
For the record:
sol# uname -a
SunOS sol 5.10 Generic_137137-09 sun4u sparc sun4u
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО11-20-2009 11:26 AM
тАО11-20-2009 11:26 AM
Re: VMS Unzip doesn't adjust for GMT
On Unix, it is possible to get the proper timestamp back by setting TZ
variable before calling unzip. However this doesn't seem to work on
VMS. Is there a comparable feature?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО11-20-2009 12:10 PM
тАО11-20-2009 12:10 PM
Re: VMS Unzip doesn't adjust for GMT
> explicitly, for uniformity purposes.
Please define "uniformity purposes". It's
not immediately clear to me how discarding
such useful information is wise, or what harm
it could do if retained.
Relevant parable:
"Doctor, it hurts when I do this."
"Don't do that."
> On Unix, it is possible to get the proper
> timestamp back [...]
And on a UNIX(-like) system, it's possible to
get the proper timestamp with no extra effort
at all, IF YOU DON'T THROW IT AWAY.
> [...] Is there a comparable feature?
I don't immediately see one. A quick look at
the code suggests that the (local) DOS
date-time in the archive is interpreted on
VMS as a local date-time. Time zones are
considered (only) when UTC is processed. No
doubt one could modify the code to do more,
but I wouldn't expect the Info-ZIP
maintainers to include it in the main code
stream. But if a man wants to carry a cat
home by its tail, I say, "Let him."
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО11-20-2009 01:29 PM
тАО11-20-2009 01:29 PM
Re: VMS Unzip doesn't adjust for GMT
$ set file/attributes=(credate=1-JAN-1980:00:00 -
moddate=1-JAN-1980:00:00) [...]*.*;*
Or (better) get Mercurial (Hg), Subversion (SVN) or some other distributed change tracking and version control software into operation, and keep one set of archives around.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО11-20-2009 01:39 PM
тАО11-20-2009 01:39 PM
Re: VMS Unzip doesn't adjust for GMT
The "uniformity" defense (actually the word I got was "indistinguishable") needs more probing on my part. Will advise when I figure it out, but all this is going on many timezones away....
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО11-20-2009 02:04 PM
тАО11-20-2009 02:04 PM
Re: VMS Unzip doesn't adjust for GMT
Yup. See if you can find anyone who can tell
you (exactly) what goes wrong if the UTC
extra fields are not removed. (We can see
what goes wrong if they are removed.)
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО11-20-2009 06:49 PM
тАО11-20-2009 06:49 PM
Re: VMS Unzip doesn't adjust for GMT
The zip files don't match unless the extra timestamp info is stripped.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО11-20-2009 07:43 PM
тАО11-20-2009 07:43 PM
Re: VMS Unzip doesn't adjust for GMT
Well, I suppose that that is a reason. Of
course, the next question would be, why do
you care? Zip archives have a built-in
checksum scheme, so it's not immediately
obvious what value an additional checksum
has, or why two different archives, even with
the same content, must be exactly identical.
Zip archives contain a local (DOS) date-time
value for each member, so I gather that
you're fooling Zip with the same TZ-setting
trick (as described above) if you're able to
create identical archives from files which
have different actual local date-time values.
All this deception is ok while it works, but
you've found a case where it breaks down.
You can fool some of the programs all of the
time, and all of the programs some of the
time, but you can't fool all of the programs
all of the time.
> Please fix, or advise on how to fix.
It's not actually broken, so I wouldn't count
on seeing a change to the official code. My
advice is to change your requirements, and
stop defeating the program features which
properly preserve file date-time values.
All the Info-ZIP source code is available,
and its license is very accommodating, so
you're welcome to alter it as you'd like,
but, as someone may once have said, "We could
do that, but it would be wrong."
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО11-20-2009 09:01 PM
тАО11-20-2009 09:01 PM
Re: VMS Unzip doesn't adjust for GMT
If I understand you correctly you're saying that since there's an internal check sum, then I must trust it? Please correct me if I'm not understanding your position here.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО11-20-2009 09:51 PM
тАО11-20-2009 09:51 PM
Re: VMS Unzip doesn't adjust for GMT
Except for the price of discarding the UTC
date-time data, and faking the local
date-time data in the archive, which I find
excessive.
> If I understand you correctly you're saying
> [...]
What I thought that I said was that I didn't
see much value in yet another checksum.
You're free to trust whatever you wish. I've
found "unzip -t" to be adequate for my
purposes.
There are all kinds of ways to create an
archive which differs from another archive,
but which would yield the same extracted
files. "zip -V" on a VMS system would add
still more extra fields. Changing the order
of the archive members should do it, too.
And so on.
I can see some value in having an md5
checksum for an archive. I can't see much
value in creating an artificially shabby
archive merely to ensure that its md5
checksum matches the one for some other
artificially shabby archive.
I don't yet see the point of building a Zip
archive which is identical to some other Zip
archive which already exists. I _can_ see
the point of building a Zip archive which
includes UTC date-time data.