Thanks. That makes sense. Best, JN On 08/31/2011 12:51 PM, Rick wrote: > According to the spec that bite is the first byte of the modification > time field. > > -- > 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. > -- > > see: http://www.gzip.org/zlib/rfc-gzip.html#file-format > > On Wed, Aug 31, 2011 at 12:35 PM, John C Nash <nashjc [ at ] uottawa [ dot ] ca> wrote: >> In preparing a backup script for my server, I wanted to tar a directory, e.g., >> >> tar czvf mydir.tar.gz /path-to-mydir/ >> >> and compare it with the "last" versions e.g., last/mydir.tar.gz >> >> Even when no changes made, if I do >> >> cmp mydir.tar.gz last/mydir.tar.gz >> >> I get >> >> mydir.tar.gz last/mydir.tar.gz differ: byte 5, line 1 >> >> This doesn't happen with zip, so I have a "sort of" workaround. However, I'm curious to >> the origin of the issue if anyone has ideas. >> >> Cheers, >> >> JN >> _______________________________________________ >> Linux mailing list >> Linux [ at ] lists [ dot ] oclug [ dot ] on [ dot ] ca >> http://oclug.on.ca/mailman/listinfo/linux >> > > >