Filestamps with UNGZIP

  • This site uses cookies. By continuing to use this site, you are agreeing to our use of cookies. Learn more.
Jun 7, 2008
121
0
#1
Hi

Using
TCC 13.00.24 Windows XP [Version 5.1.2600]

If I do

UNGZIP /v m:..\PET\B20100809ORIG.PET.Z

I see

2010-08-17 21:03 B20100809.PET

But if I do

UNGZIP m:..\PET\B20100809ORIG.PET.Z

and then DIR
I see

12/10/2011 20:11 51,144,799 B20100809.PET

Question:
On ungzipping, why is the date and time filestamp not 21:03 17-08-2010 instead of todays date/time?

I have just checked

unzip => that works, filestamp is restored
untar => that works, filestamp is restored

Thanks

Stephen Howe
 
Jun 7, 2008
121
0
#3
Thanks Rex

But suggestion:

Surely if TC can "see" the filestamp with /V, then if available, it could set it after extraction?

Alternatively, could you suggest to the library vendors of the option of setting the filestamp if available?

Thanks

Stephen
 
Jul 1, 2008
81
0
70
Montreal
#4
Thanks Rex

But suggestion:

Surely if TC can "see" the filestamp with /V, then if available, it could set it after extraction?

Alternatively, could you suggest to the library vendors of the option of setting the filestamp if available?

Thanks

Stephen
I wholeheartedly agree, timestamp support is a feature I have long considered important in file compressors. The file creation timestamp already informs us when a file was last extracted from an archive, but what's important is the file modification timestamp. I just bought Bob Dylan's "Highway 61 Revisited", TAR says it's his very latest release...
--
Peter
 

rconn

Administrator
Staff member
May 14, 2008
10,100
85
#5
\
Surely if TC can "see" the filestamp with /V, then if available, it could set it after extraction?
But what is shown with /V is *not* the modification date/time, it's the date/time that the file was archived. I don't think that's going to be any more "valid" than the current date/time. (Again, it is not TCC doing this, it's the compression library.)

And don't call me Shirley ...
 
Jun 7, 2008
121
0
#6
But what is shown with /V is *not* the modification date/time, it's the date/time that the file was archived. I don't think that's going to be any more "valid" than the current date/time. (Again, it is not TCC doing this, it's the compression library.)

And don't call me Shirley ...
Okay, I accept that.
I wrote a GZIP unzipper myself as the ZLIB 1.2.3 libraries did not entirely work for GZIP files (confirmed) and the ZLIB 1.2.5 libraries have been built with different segment attributes (confuses Microsoft LINK. Must check to see if they have fixed this). I have to read the GZIP header myself and then call ZLIB 1.2.3 for uncompression.

So I may come back to this, once I have refreshed my memory on GZIP documentation.

Thanks

Stephen Howe
 
#7
But what is shown with /V is *not* the modification date/time, it's the date/time that the file was archived. I don't think that's going to be any more "valid" than the current date/time. (Again, it is not TCC doing this, it's the compression library.)
WOW. pkunzip's -v option, from the very beginning, shows the file's modification date/time (and restores it upon unarchiving). I'm going to have to stick with it for quite some more time...

(yes, I know it's the library's fault)
 
Jun 7, 2008
121
0
#9
But what is shown with /V is *not* the modification date/time, it's the date/time that the file was archived. I don't think that's going to be any more "valid" than the current date/time. (Again, it is not TCC doing this, it's the compression library.)

And don't call me Shirley ...
Hi. The GZIP header format can stash away the modifcation date/time.
See
RFC 1952 GZIP File Format Specification version 4.3
where it has
>>
MTIME (Modification TIME)
This gives the most recent modification time of the original file being compressed. The time is in Unix format, i.e., seconds since 00:00:00 GMT, Jan. 1, 1970. (Note that this may cause problems for MS-DOS and other systems that use local rather than Universal time.) If the compressed data did not come from a file, MTIME is set to the time at which compression started. MTIME = 0 means no time stamp is available.
>>

So only if MTIME is 0 is no filestamp available.

Stephen Howe