Subject: Re: bug#29265: gzip-1.8.41 test results: timestamp

From: Paul Eggert <[email-masked]>
Date: Sun, 12 Nov 2017 00:25:23 -0800

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.
From b1d08ed0e26f0a8c81910c5950275d28ce06bd9c Mon Sep 17 00:00:00 2001
From: Paul Eggert <[email-masked]>
Date: Sun, 12 Nov 2017 00:20:04 -0800
Subject: [PATCH] =?UTF-8?q?tests:=20don=E2=80=99t=20be=20so=20strict=20abo?=
 =?UTF-8?q?ut=20timestamps?=
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

* tests/timestamp: We’ve had many false alarms about timestamps
that are not gzip problems, but instead are problems with ‘touch’.
Attempt to work around them by not trusting ‘touch’ so much.
Problems and parts of solutions proposed by Bruno Haible.
---
 tests/timestamp | 49 ++++++++++++++++++++++++++++++++++++++-----------
 1 file changed, 38 insertions(+), 11 deletions(-)

diff --git a/tests/timestamp b/tests/timestamp
index 6e4e1fc..8ef6901 100755
--- a/tests/timestamp
+++ b/tests/timestamp
@@ -21,31 +21,58 @@
 
 TZ=UTC0
 export TZ
+oldIFS=$IFS
 
 # On platforms supporting timestamps outside gzip's range,
 # test that gzip warns when converting them to gzip format.
-for time in 190101010000 196912312359.59 197001010000 210602070628.16; do
+for time_date in \
+    '190101010000~Jan  1  1901' \
+    '196912312359.59~Dec 31  1969' \
+    '197001010000~Jan  1  1970' \
+    '210602070628.16~Feb  7  2106'
+do
+  IFS='~'
+  set $time_date
+  time=$1
+  date=$2
+  IFS=$oldIFS
   if touch -t $time in; then
-     returns_ 2 gzip in || fail=1
+    ls_l=$(ls -l in)
+    case $ls_l in
+      *"$date"*) returns_ 2 gzip in || fail=1;;
+    esac
   fi
   rm -f in.gz in
 done
 
 # Test that timestamps in range for gzip do not generate warnings.
-for time in 197001010000.01 203801190314.07 203801190314.08 210602070628.15; do
+for time_date in \
+    '197001010000.01~Jan  1  1970' \
+    '203801190314.07~Jan 19  2038' \
+    '203801190314.08~Jan 19  2038' \
+    '210602070628.15~Feb  7  2106'
+do
+  IFS='~'
+  set $time_date
+  time=$1
+  date=$2
+  IFS=$oldIFS
   if touch -t $time in; then
-     gzip in || fail=1
+    ls_l=$(ls -l in)
+    case $ls_l in
+      *"$date"*) gzip in || fail=1;;
+    esac
   fi
   rm -f in.gz in
 done
 
-# On platforms that fail to support timestamps within gzip's range,
-# test that gzip warns when converting them from gzip format.
-touch -t 210602070628.15 in || {
-  printf '\037\213\10\0\377\377\377\377\0\377\3\0\0\0\0\0\0\0\0\0' >y2106.gz ||
-    framework_failure_
-  returns_ 2 gzip -Nlv <y2106.gz || fail=1
-}
+# Test that gzip succeeds when converting timestamps from gzip format,
+# or warns that the timestamp is out of time_t range.
+printf '\037\213\10\0\377\377\377\377\0\377\3\0\0\0\0\0\0\0\0\0' >y2106.gz ||
+  framework_failure_
+gzip -Nlv <y2106.gz
+status=$?
+test $status -eq 0 || test $status -eq 2 || fail=1
 
 # Ensure that --no-name does not provoke a timestamp warning.
 : | gzip --no-name > k || fail=1
-- 
2.7.4