Re: a coreutils release is imminent

[Matthew Woehlke]

Jim Meyering wrote:
> Matthew Woehlke wrote:
> ...
> > Ok, I finally bit the bullet and figured out how to build perl. (Talk
> > about ugly build systems... I feel unclean.) It croaked once on tty-eof
> > but skipped it after I nuked the dir and started clean from the tarball,
> > so that was probably because I installed a working perl after running
> > configure.
>
> Thanks for checking.

Hey, I plan on installing this sucker! I want it to work... :-D

> > So I guess sort-compress is the only remaining severe failure, failing
>
> In my book, this is an unimportant failure.
> First, this is a brand new option.  No existing script uses it.
> Second, on most systems it doesn't fail so easily.

Ok, as long as it's known to be broken.

> > 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.

However... what is different about OSF (versus, say, x86/Solaris) that 
it sets the time stamp on a file on an NFS volume to the *local host's* 
clock, rather than the NFS server's clock? On an x86/Solaris box (that 
happens to be about six minutes fast), 'touch a' (coreutils 6.6) and '> 
a' result in the same (correct (the NFS server is correct), but not 
matching the local host's clock) time stamp.

--
Matthew
Congratulations! You've won a free trip to the future! All you have to 
do to claim your prize is wait five minutes...