Re: a coreutils release is imminent

[Jim Meyering]

Matthew Woehlke <address@hidden> wrote:
> Jim Meyering wrote:
>> Matthew Woehlke wrote:
...
>>> However, I am seeing one more failure on OSF: touch/empty-file. Both the
>>> local clock and the NFS clock incorrectly report PST, but otherwise
>>> appear to be in sync:
>> ...
>>> Here's the verbose output (which I admit I am looking at, and don't
>>> understand...):
>> ...
>>> + echo sleeping for 3 seconds...
>>> sleeping for 3 seconds...
>>> + sleep 3
>>> + touch ./a
>>> + ls -t ./a ./b
>>> + set x ./b ./a
>>> + test x ./b ./a = x ./a ./b
>>> + fail=1
>> This looks like a bug on that system.
>> Touching "a" 3s after "b", then running "ls -t a b",
>> the result should list the newer-mtime "a" before "b".
>
> Um. I added 'ls -t --full-time $d/a $d/b ; date' to the test, and got this:
>
> -rw-r--r-- 1 install sqe 0 2007-03-21 13:42:31.590078000 -0800 ./b
> -rw-r--r-- 1 install sqe 0 2007-03-21 13:21:20.009964000 -0800 ./a
>
> ...yike! Hmm... ok, *now* I see the problem. It turns out this box's
> clock is WAAAAY off (about 21 minutes). So I guess this can be ignored.

Yep.  As you probably noticed, that's what the failing test suggested:

  *** This test has just failed.  That can happen when the test is run in an
  *** NFS-mounted directory on a system whose clock is not well synchronized
  *** with that of the NFS server.  If you think that is the reason, set the
  *** environment variable SLEEP_SECONDS to some number of seconds larger than
  *** the default of $DEFAULT_SLEEP_SECONDS and rerun the test.