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
>
--
They must find it difficult...
Those who have taken authority as the truth,
Rather than truth as the authority.
G. Massey, Egyptologist