1. This site uses cookies. By continuing to use this site, you are agreeing to our use of cookies. Learn More.

Filestamps with UNGZIP

Discussion in 'Support' started by Stephen Howe, Oct 12, 2011.

  1. Stephen Howe

    Joined:
    Jun 7, 2008
    Messages:
    121
    Likes Received:
    0
    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
     
  2. rconn

    rconn Administrator
    Staff Member

    Joined:
    May 14, 2008
    Messages:
    9,854
    Likes Received:
    83
    UNGZIP doesn't support setting the date stamp (library limitation, not TCC).
     
  3. Stephen Howe

    Joined:
    Jun 7, 2008
    Messages:
    121
    Likes Received:
    0
    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
     
  4. Peter Bratton

    Joined:
    Jul 1, 2008
    Messages:
    81
    Likes Received:
    0
    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
     
  5. rconn

    rconn Administrator
    Staff Member

    Joined:
    May 14, 2008
    Messages:
    9,854
    Likes Received:
    83
    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 ...
     
  6. Stephen Howe

    Joined:
    Jun 7, 2008
    Messages:
    121
    Likes Received:
    0
    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. mfarah

    Joined:
    Nov 2, 2009
    Messages:
    226
    Likes Received:
    5
    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)
     
  8. rconn

    rconn Administrator
    Staff Member

    Joined:
    May 14, 2008
    Messages:
    9,854
    Likes Received:
    83
    We're talking about GZIP and .gz files, not ZIP and .zip files.

    ZIP /V shows the file modification date/time.
     
  9. Stephen Howe

    Joined:
    Jun 7, 2008
    Messages:
    121
    Likes Received:
    0
    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
     
  10. mfarah

    Joined:
    Nov 2, 2009
    Messages:
    226
    Likes Received:
    5
    OOPS. Sorry...

    I really need to sleep for a couple days straight. :-(
     

Share This Page