[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#29265: gzip-1.8.41 test results: timestamp

From: Paul Eggert
Subject: bug#29265: gzip-1.8.41 test results: timestamp
Date: Sun, 12 Nov 2017 00:25:23 -0800
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0

Bruno Haible wrote:

Since Paul asked about more details on this one in
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.

Attachment: 0001-tests-don-t-be-so-strict-about-timestamps.txt
Description: Text document

reply via email to

[Prev in Thread] Current Thread [Next in Thread]