GNU bug report logs - #29265
gzip-1.8.41 test results: timestamp

Previous Next

Package: gzip;

Reported by: Bruno Haible <bruno <at> clisp.org>

Date: Sat, 11 Nov 2017 23:37:01 UTC

Severity: normal

Done: Paul Eggert <eggert <at> cs.ucla.edu>

Bug is archived. No further changes may be made.

Full log


View this message in rfc822 format

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Bruno Haible <bruno <at> clisp.org>, 29265 <at> debbugs.gnu.org
Subject: bug#29265: gzip-1.8.41 test results: timestamp
Date: Sun, 12 Nov 2017 00:25:23 -0800
[Message part 1 (text/plain, inline)]
Bruno Haible wrote:

> Since Paul asked about more details on this one in
> https://lists.gnu.org/archive/html/bug-gzip/2017-11/msg00005.html
> here are more details (on OpenBSD/i386):
> 
> $ make check TESTS=timestamp VERBOSE=yes > timestamp.x 2>&1

Thanks. I am puzzled by the failures. For example:

> + touch -t 190101010000 in
> + returns_ 2 gzip in
> + fail=1

Here, 'touch' succeeded, but gzip did not diagnose the negative timestamp. Do 
other programs report that the timestamp is 1901? For example, what is the 
output of this?

  export TZ=UTC0
  touch -t 190101010000 in
  ls -l in

Likewise for the timestamps 203801190314.08 and 210602070628.15, both of which 
are out of range for gzip but gzip did not diagnose it.

I installed the attached patch to tests/timestamp, partly in response to your 
earlier advice that we can't trust 'touch' to have the same time_t range as 
'gzip', and partly in response to the abovementioned failures. This patch uses 
'ls' to check the timestamp that 'touch' succeeded on. If the check fails, we 
don't bother to try 'gzip' on the same timestamp since the files' timestamp is 
dicey. Although this weakens the gzip testing, that's probably better than all 
these false alarms. This should fix some of the timestamp failures that you have 
reported.

While testing this, I discovered that on Solaris 10 and 11, file timestamps 
before the Epoch result in tv_nsec < 0! This bug is new to me. I plan to look 
into that bug separately. I expect that the best way to work around it is to add 
Gnulib code to fix the bogus timestamps.
[0001-tests-don-t-be-so-strict-about-timestamps.txt (text/plain, attachment)]

This bug report was last modified 2 years and 229 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.