GNU bug report logs - #7198
ls-misc failure with Oct 10 snapshot

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 7198 in the body.
You can then email your comments to 7198 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Bug-coreutils <bug-coreutils <at> gnu.org>
Subject: ls-misc failure with Oct 10 snapshot
Date: Tue, 12 Oct 2010 09:49:12 -0700

I got this on RHEL 5 x86-64 compiled with my own GCC 4.5.1.
Haven't had time to look into it.  Those escape
sequences are annoying....

FAIL: misc/ls-misc (exit: 1)
============================

ls (GNU coreutils) 8.5.188-9af44
Copyright (C) 2010 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>.
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Written by Richard M. Stallman and David MacKenzie.
q-...
q-N...
q-q...
q-Q...
q-lit-q...
q-qs-lit...
q-qs-sh...
q-qs-sh-a...
q-qs-c...
q-qs-esc...
q-qs-c-1...
emptydir...
emptydir-x2...
emptydir-R...
R-dot...
slink-dir-F...
Use of uninitialized value in scalar assignment at ./misc/ls-misc line 36.
slink-dir-dF...
Use of uninitialized value in scalar assignment at ./misc/ls-misc line 36.
slinkdir-dFH...
Use of uninitialized value in scalar assignment at ./misc/ls-misc line 36.
slinkdir-dFL...
Use of uninitialized value in scalar assignment at ./misc/ls-misc line 36.
sl-F-color...
Use of uninitialized value in scalar assignment at ./misc/ls-misc line 36.
sl-dF-color...
Use of uninitialized value in scalar assignment at ./misc/ls-misc line 36.
no-c-empty...
no-c-reg...
sl-target...
Use of uninitialized value in scalar assignment at ./misc/ls-misc line 36.
sl-dangle...
Use of uninitialized value in scalar assignment at ./misc/ls-misc line 36.
sl-dangle2...
Use of uninitialized value in scalar assignment at ./misc/ls-misc line 36.
sl-dangle3...
ls-misc: test sl-dangle3: stdout mismatch, comparing sl-dangle3.O (actual) and sl-dangle3.1 (expected)
*** sl-dangle3.O	Tue Oct 12 09:12:22 2010
--- sl-dangle3.1	Tue Oct 12 09:12:22 2010
***************
*** 1 ****
! lrwxrwxrwx 1 eggert 7 Oct 12  2010 l -> nowhere
--- 1 ----
! l -> nowhere
Use of uninitialized value in scalar assignment at ./misc/ls-misc line 36.
sl-dangle4...
ls-misc: test sl-dangle4: stdout mismatch, comparing sl-dangle4.O (actual) and sl-dangle4.1 (expected)
*** sl-dangle4.O	Tue Oct 12 09:12:22 2010
--- sl-dangle4.1	Tue Oct 12 09:12:22 2010
***************
*** 1 ****
! lrwxrwxrwx 1 eggert 7 Oct 12  2010 l -> nowhere
--- 1 ----
! l -> nowhere
Use of uninitialized value in scalar assignment at ./misc/ls-misc line 36.
sl-dangle5...
ls-misc: test sl-dangle5: stdout mismatch, comparing sl-dangle5.O (actual) and sl-dangle5.1 (expected)
*** sl-dangle5.O	Tue Oct 12 09:12:22 2010
--- sl-dangle5.1	Tue Oct 12 09:12:22 2010
***************
*** 1 ****
! lrwxrwxrwx 1 eggert 7 Oct 12  2010 l -> nowhere
--- 1 ----
! l -> nowhere
Use of uninitialized value in scalar assignment at ./misc/ls-misc line 36.
color-exe1...
Use of uninitialized value in scalar assignment at ./misc/ls-misc line 36.
no-a-isdir-b...
recursive-2...
setuid-etc...
file-type...
version-sort...
multi-arg-U1...

Message #8 received at 7198 <at> debbugs.gnu.org (full text, mbox):

From: Jim Meyering <jim <at> meyering.net>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: 7198 <at> debbugs.gnu.org
Subject: Re: bug#7198: ls-misc failure with Oct 10 snapshot
Date: Tue, 12 Oct 2010 19:57:55 +0200

Paul Eggert wrote:
> I got this on RHEL 5 x86-64 compiled with my own GCC 4.5.1.
> Haven't had time to look into it.  Those escape
> sequences are annoying....

Hi Paul,

Thanks for the report.
What version of RHEL 5.N?  I.e., what's "N"?
I couldn't reproduce that on a 5.5 x86-based system using /usr/bin/gcc.
Can you reproduce it with the standard compiler?
What does perl -v print?

> FAIL: misc/ls-misc (exit: 1)
> ============================
>
> ls (GNU coreutils) 8.5.188-9af44
> Copyright (C) 2010 Free Software Foundation, Inc.
> License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>.
> This is free software: you are free to change and redistribute it.
> There is NO WARRANTY, to the extent permitted by law.
>
> Written by Richard M. Stallman and David MacKenzie.
> q-...
> q-N...
> q-q...
> q-Q...
> q-lit-q...
> q-qs-lit...
> q-qs-sh...
> q-qs-sh-a...
> q-qs-c...
> q-qs-esc...
> q-qs-c-1...
> emptydir...
> emptydir-x2...
> emptydir-R...
> R-dot...
> slink-dir-F...
> Use of uninitialized value in scalar assignment at ./misc/ls-misc line 36.

Odd that you get those warnings and I don't.
At first I thought I might be able to reproduce the warning
by removing LS_COLORS from my environment, but that didn't work.

Can you see if this gets rid of those warnings?

diff --git a/tests/misc/ls-misc b/tests/misc/ls-misc
index e663a5f..b0c5dce 100755
--- a/tests/misc/ls-misc
+++ b/tests/misc/ls-misc
@@ -27,7 +27,7 @@ my $saved_ls_colors;

 sub push_ls_colors($)
 {
-  $saved_ls_colors = $ENV{LS_COLORS};
+  $saved_ls_colors = $ENV{LS_COLORS} || '';
   $ENV{LS_COLORS} = $_[0];
 }

The failures make it look like ls is being run without the -o option.

If you rerun the test with DEBUG=yes, e.g.,

  make check -C tests TESTS=misc/ls-misc VERBOSE=yes DEBUG=yes

that might give a hint...

...
> ls-misc: test sl-dangle3: stdout mismatch, comparing sl-dangle3.O (actual) and sl-dangle3.1 (expected)
> *** sl-dangle3.O	Tue Oct 12 09:12:22 2010
> --- sl-dangle3.1	Tue Oct 12 09:12:22 2010
> ***************
> *** 1 ****
> ! lrwxrwxrwx 1 eggert 7 Oct 12  2010 l -> nowhere
> --- 1 ----
> ! l -> nowhere
> Use of uninitialized value in scalar assignment at ./misc/ls-misc line 36.
> sl-dangle4...
> ls-misc: test sl-dangle4: stdout mismatch, comparing sl-dangle4.O (actual) and sl-dangle4.1 (expected)
> *** sl-dangle4.O	Tue Oct 12 09:12:22 2010
> --- sl-dangle4.1	Tue Oct 12 09:12:22 2010
> ***************
> *** 1 ****
> ! lrwxrwxrwx 1 eggert 7 Oct 12  2010 l -> nowhere
> --- 1 ----
> ! l -> nowhere
> Use of uninitialized value in scalar assignment at ./misc/ls-misc line 36.
> sl-dangle5...
> ls-misc: test sl-dangle5: stdout mismatch, comparing sl-dangle5.O (actual) and sl-dangle5.1 (expected)
> *** sl-dangle5.O	Tue Oct 12 09:12:22 2010
> --- sl-dangle5.1	Tue Oct 12 09:12:22 2010
> ***************
> *** 1 ****
> ! lrwxrwxrwx 1 eggert 7 Oct 12  2010 l -> nowhere
> --- 1 ----
> ! l -> nowhere
> Use of uninitialized value in scalar assignment at ./misc/ls-misc line 36.
> color-exe1...
> Use of uninitialized value in scalar assignment at ./misc/ls-misc line 36.
> no-a-isdir-b...
> recursive-2...
> setuid-etc...
> file-type...
> version-sort...
> multi-arg-U1...

Message #11 received at 7198 <at> debbugs.gnu.org (full text, mbox):

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Jim Meyering <jim <at> meyering.net>
Cc: 7198 <at> debbugs.gnu.org
Subject: Re: bug#7198: ls-misc failure with Oct 10 snapshot
Date: Tue, 12 Oct 2010 16:42:38 -0700

On 10/12/10 10:57, Jim Meyering wrote:

> What version of RHEL 5.N?  I.e., what's "N"?

/etc/issue says "Red Hat Enterprise Linux Server release 5.5 (Tikanga)".
uname -a says "Linux lnxsrv01.seas.ucla.edu 2.6.18-194.17.1.el5 #1 SMP Mon Sep 20 07:12:06 EDT 2010 x86_64 GNU/Linux".

> What does perl -v print?

This is perl, v5.8.8 built for x86_64-linux-thread-multi

> I couldn't reproduce that on a 5.5 x86-based system using
> /usr/bin/gcc. Can you reproduce it with the standard compiler?

Ouch.  Now I can't reproduce the problem with either the standard
compiler or with my GCC 4.5.1.  However, with the standard compiler
I get different problems.

test-rand-isaac.c: In function 'main':                                          
test-rand-isaac.c:599: warning: passing argument 2 of 'strtol' makes pointer fr\
om integer without a cast                                                       
test-rand-isaac.c:599: warning: passing argument 3 of 'strtol' makes integer fr\
om pointer without a cast        

Something odd is going on here, as that's an obvious typo in the
test case that GCC 4.5.1 should also have caught.  Dunno why it
didn't, and don't know why you didn't notice that problem on your
end, with the standard compiler.

Oh, and when running atop an NFS file system I found another problem,
which occurs with both the standard gcc and with my GCC 4.5.1:

FAIL: test-rename (exit: 134)
=============================

test-rename.h:121: assertion failed

Here's the output of "strace ./test-rename" in gnulib-tests:

mkdir("test-rename.tdir2", 0700)        = 0
creat("test-rename.tdir/file", 0600)    = 4
close(4)                                = 0
rename("test-rename.tdir2", "test-rename.tdir") = -1 ENOTEMPTY (Directory not empty)
rename("test-rename.tdir2/", "test-rename.tdir") = -1 ENOTEMPTY (Directory not empty)
rename("test-rename.tdir2", "test-rename.tdir/") = -1 ENOTEMPTY (Directory not empty)
rename("test-rename.tdir", "test-rename.tdir2") = 0
stat("test-rename.tdir", {st_mode=S_IFDIR|0700, st_size=4096, ...}) = 0
write(2, "test-rename.h:121: assertion fai"..., 36test-rename.h:121: assertion failed
) = 36

The amusing thing is that, after the strace, "ls -l test-rename.t*"
reports only this:

$ ls -ltd test-rename.tdir*
drwx------ 2 eggert csfac 4096 Oct 12 16:35 test-rename.tdir2

Perhaps there's a bug in the RHEL 5.5 NFS client?  That might
conceivably explain the misc/ls-misc problem that started this thread.

I'll try to look into this more latter; gotta run now.

Message #14 received at 7198 <at> debbugs.gnu.org (full text, mbox):

From: Jim Meyering <jim <at> meyering.net>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: 7198 <at> debbugs.gnu.org
Subject: Re: bug#7198: ls-misc failure with Oct 10 snapshot
Date: Wed, 13 Oct 2010 09:09:21 +0200

Paul Eggert wrote:
> On 10/12/10 10:57, Jim Meyering wrote:
>
>> What version of RHEL 5.N?  I.e., what's "N"?
>
> /etc/issue says "Red Hat Enterprise Linux Server release 5.5 (Tikanga)".
> uname -a says "Linux lnxsrv01.seas.ucla.edu 2.6.18-194.17.1.el5 #1 SMP Mon Sep 20 07:12:06 EDT 2010 x86_64 GNU/Linux".
>
>> What does perl -v print?
>
> This is perl, v5.8.8 built for x86_64-linux-thread-multi
>
>> I couldn't reproduce that on a 5.5 x86-based system using
>> /usr/bin/gcc. Can you reproduce it with the standard compiler?
>
> Ouch.  Now I can't reproduce the problem with either the standard
> compiler or with my GCC 4.5.1.  However, with the standard compiler
> I get different problems.
>
> test-rand-isaac.c: In function 'main':
> test-rand-isaac.c:599: warning: passing argument 2 of 'strtol' makes pointer fr\
> om integer without a cast
> test-rand-isaac.c:599: warning: passing argument 3 of 'strtol' makes integer fr\
> om pointer without a cast
>
> Something odd is going on here, as that's an obvious typo in the
> test case that GCC 4.5.1 should also have caught.  Dunno why it
> didn't, and don't know why you didn't notice that problem on your
> end, with the standard compiler.

Wow.  That's pretty bad.
Just goes to show (yet again) that we really should be using -Werror also
in gnulib-tests.  But not all maintainers of gnulib's tests have the same
standards/tolerance/expectation for warning levels, so it'll take some work.

I'm about to push this in your name:

From 9300fffcb54006bf471d96d70cf98081152c6fb1 Mon Sep 17 00:00:00 2001
From: Paul Eggert <eggert <at> cs.ucla.edu>
Date: Wed, 13 Oct 2010 09:03:41 +0200
Subject: [PATCH] tests: fix rand-isaac test

* gl/tests/test-rand-isaac.c (main): Fix swapped arguments to strtol.
---
 gl/tests/test-rand-isaac.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/gl/tests/test-rand-isaac.c b/gl/tests/test-rand-isaac.c
index 03b004c..90acb4a 100644
--- a/gl/tests/test-rand-isaac.c
+++ b/gl/tests/test-rand-isaac.c
@@ -594,7 +594,7 @@ main (int argc, char **argv)

   /* If invoked with a positive argument, run a benchmark;
      if with a negative, run a do-nothing benchmark.  */
-  for (iterations = argc <= 1 ? 0 : strtol (argv[1], 10, NULL);
+  for (iterations = argc <= 1 ? 0 : strtol (argv[1], NULL, 10);
        iterations != 0;
        iterations += (iterations < 0 ? 1 : -1))
     if (0 <= iterations)
--
1.7.3.1.104.gc752e

Message #17 received at 7198 <at> debbugs.gnu.org (full text, mbox):

From: Jim Meyering <jim <at> meyering.net>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: 7198 <at> debbugs.gnu.org
Subject: Re: bug#7198: ls-misc failure with Oct 10 snapshot
Date: Wed, 13 Oct 2010 09:37:06 +0200

Paul Eggert wrote:
> On 10/12/10 10:57, Jim Meyering wrote:
>
>> What version of RHEL 5.N?  I.e., what's "N"?
>
> /etc/issue says "Red Hat Enterprise Linux Server release 5.5 (Tikanga)".
> uname -a says "Linux lnxsrv01.seas.ucla.edu 2.6.18-194.17.1.el5 #1 SMP Mon Sep 20 07:12:06 EDT 2010 x86_64 GNU/Linux".
...
> Oh, and when running atop an NFS file system I found another problem,
> which occurs with both the standard gcc and with my GCC 4.5.1:
>
> FAIL: test-rename (exit: 134)
> =============================
>
> test-rename.h:121: assertion failed
>
> Here's the output of "strace ./test-rename" in gnulib-tests:
>
> mkdir("test-rename.tdir2", 0700)        = 0
> creat("test-rename.tdir/file", 0600)    = 4
> close(4)                                = 0
> rename("test-rename.tdir2", "test-rename.tdir") = -1 ENOTEMPTY (Directory not empty)
> rename("test-rename.tdir2/", "test-rename.tdir") = -1 ENOTEMPTY (Directory not empty)
> rename("test-rename.tdir2", "test-rename.tdir/") = -1 ENOTEMPTY (Directory not empty)
> rename("test-rename.tdir", "test-rename.tdir2") = 0
> stat("test-rename.tdir", {st_mode=S_IFDIR|0700, st_size=4096, ...}) = 0
> write(2, "test-rename.h:121: assertion fai"..., 36test-rename.h:121: assertion failed
> ) = 36

That's not good.  It looks like a race, where the client thinks the
source of the rename is still there for some short interval after the
rename succeeded.

What is the server running?

> The amusing thing is that, after the strace, "ls -l test-rename.t*"
> reports only this:
>
> $ ls -ltd test-rename.tdir*
> drwx------ 2 eggert csfac 4096 Oct 12 16:35 test-rename.tdir2
>
> Perhaps there's a bug in the RHEL 5.5 NFS client?

There's definitely something suspicious going on...

> That might
> conceivably explain the misc/ls-misc problem that started this thread.

First step for that one should be to avoid the warnings from perl,
e.g., via the patch I suggested.

> I'll try to look into this more latter; gotta run now.

Thanks.

Message #20 received at 7198 <at> debbugs.gnu.org (full text, mbox):

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Jim Meyering <jim <at> meyering.net>
Cc: 7198 <at> debbugs.gnu.org
Subject: Re: bug#7198: ls-misc failure with Oct 10 snapshot
Date: Wed, 13 Oct 2010 23:45:57 -0700

On 10/13/2010 12:37 AM, Jim Meyering wrote:

> What is the server running?

NetApp 6.5.6.  NFS is configured to be NFSv3, running over TCP.

> First step for that one should be to avoid the warnings from perl,
> e.g., via the patch I suggested.

Yes, thanks, somehow I missed the patch to tests/misc/ls-misc
that you suggested in
<http://lists.gnu.org/archive/html/bug-coreutils/2010-10/msg00038.html>.
I just tried it now, and it does fix the perl warnings.

The problem goes away if I do the build on a local disk, so it does
seem to be specific to NFS.

I reproduced the problem with the standard RHEL tools, i.e., without
using the newer versions of GCC etc. that I normally use.

When I strace the make, the bug goes away.  This indicates that it's
timing-related, and may be hard to debug.

Ooo! Ooo!  The "timing-related" in the previous paragraph made the
light bulb go on in my head.  It's clock skew.  The NFS server's
clock is a tiny bit ahead of the NFS client's clock, and so the output
of "ls -l" contains the date, not the time.

I don't see how clock-skew could also explain the test-rename bug noted in
<http://lists.gnu.org/archive/html/bug-coreutils/2010-10/msg00050.html>,
though.  That part of NFS is not supposed to care about clock skew.

Anyway, the following combined patch fixes the ls-misc failure:

From 1c1b06cbda069991be012f8171d41a713627b30f Mon Sep 17 00:00:00 2001
From: Paul Eggert <eggert <at> cs.ucla.edu>
Date: Wed, 13 Oct 2010 23:39:50 -0700
Subject: [PATCH] tests: work around portability and clock-skew problems

* tests/misc/ls-misc (push_ls_colors): Don't assume LS_COLORS
is set.  This part of the fix is by Jim Meyering.
(sl-dangle2, sl-dangle3, sl-dangle4, sl-dangle5): Don't assume
that newly-created files will have time stamps in the past.  They
might not, due to clock skew, if the file systems are remote.
---
 tests/misc/ls-misc |   18 +++++++++---------
 1 files changed, 9 insertions(+), 9 deletions(-)

diff --git a/tests/misc/ls-misc b/tests/misc/ls-misc
index e663a5f..9e38038 100755
--- a/tests/misc/ls-misc
+++ b/tests/misc/ls-misc
@@ -27,7 +27,7 @@ my $saved_ls_colors;
 
 sub push_ls_colors($)
 {
-  $saved_ls_colors = $ENV{LS_COLORS};
+  $saved_ls_colors = $ENV{LS_COLORS} || '';
   $ENV{LS_COLORS} = $_[0];
 }
 
@@ -186,8 +186,8 @@ my @Tests =
      ],
 
      # Test for a bug fixed after coreutils-8.2.
-     ['sl-dangle2', '-o --color=always l',
-      {OUT_SUBST => 's/.*[0-9][0-9]:[0-9][0-9] //'},
+     ['sl-dangle2', '-o --time-style=+:TIME: --color=always l',
+      {OUT_SUBST => 's/.*:TIME: //'},
       {OUT => "l -> nowhere\n"},
       {PRE => sub {symlink 'nowhere', 'l' or die "l: $!\n";
                    push_ls_colors('ln=target')
@@ -195,8 +195,8 @@ my @Tests =
       {POST => sub {unlink 'l' or die "l: $!\n";
                     restore_ls_colors; }},
      ],
-     ['sl-dangle3', '-o --color=always l',
-      {OUT_SUBST => 's/.*[0-9][0-9]:[0-9][0-9] //'},
+     ['sl-dangle3', '-o --time-style=+:TIME: --color=always l',
+      {OUT_SUBST => 's/.*:TIME: //'},
       {OUT => "$e\e[40ml$e -> \e[34mnowhere$e\n"},
       {PRE => sub {symlink 'nowhere', 'l' or die "l: $!\n";
                    push_ls_colors('ln=target:or=40:mi=34:')
@@ -204,8 +204,8 @@ my @Tests =
       {POST => sub {unlink 'l' or die "l: $!\n";
                     restore_ls_colors; }},
      ],
-     ['sl-dangle4', '-o --color=always l',
-      {OUT_SUBST => 's/.*[0-9][0-9]:[0-9][0-9] //'},
+     ['sl-dangle4', '-o --time-style=+:TIME: --color=always l',
+      {OUT_SUBST => 's/.*:TIME: //'},
       {OUT => "$e\e[36ml$e -> \e[35mnowhere$e\n"},
       {PRE => sub {symlink 'nowhere', 'l' or die "l: $!\n";
                    push_ls_colors('ln=34:mi=35:or=36:')
@@ -213,8 +213,8 @@ my @Tests =
       {POST => sub {unlink 'l' or die "l: $!\n";
                     restore_ls_colors; }},
      ],
-     ['sl-dangle5', '-o --color=always l',
-      {OUT_SUBST => 's/.*[0-9][0-9]:[0-9][0-9] //'},
+     ['sl-dangle5', '-o --time-style=+:TIME: --color=always l',
+      {OUT_SUBST => 's/.*:TIME: //'},
       {OUT => "$e\e[34ml$e -> \e[35mnowhere$e\n"},
       {PRE => sub {symlink 'nowhere', 'l' or die "l: $!\n";
                    push_ls_colors('ln=34:mi=35:')
-- 
1.7.2

Message #23 received at 7198 <at> debbugs.gnu.org (full text, mbox):

From: Jim Meyering <jim <at> meyering.net>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: 7198 <at> debbugs.gnu.org
Subject: Re: bug#7198: ls-misc failure with Oct 10 snapshot
Date: Thu, 14 Oct 2010 09:26:01 +0200

Paul Eggert wrote:
> On 10/13/2010 12:37 AM, Jim Meyering wrote:
>
>> What is the server running?
>
> NetApp 6.5.6.  NFS is configured to be NFSv3, running over TCP.
>
>> First step for that one should be to avoid the warnings from perl,
>> e.g., via the patch I suggested.
>
> Yes, thanks, somehow I missed the patch to tests/misc/ls-misc
> that you suggested in
> <http://lists.gnu.org/archive/html/bug-coreutils/2010-10/msg00038.html>.
> I just tried it now, and it does fix the perl warnings.
>
> The problem goes away if I do the build on a local disk, so it does
> seem to be specific to NFS.
>
> I reproduced the problem with the standard RHEL tools, i.e., without
> using the newer versions of GCC etc. that I normally use.
>
> When I strace the make, the bug goes away.  This indicates that it's
> timing-related, and may be hard to debug.
>
> Ooo! Ooo!  The "timing-related" in the previous paragraph made the
> light bulb go on in my head.  It's clock skew.  The NFS server's
> clock is a tiny bit ahead of the NFS client's clock, and so the output
> of "ls -l" contains the date, not the time.

Good catch!

> I don't see how clock-skew could also explain the test-rename bug noted in
> <http://lists.gnu.org/archive/html/bug-coreutils/2010-10/msg00050.html>,
> though.  That part of NFS is not supposed to care about clock skew.
>
> Anyway, the following combined patch fixes the ls-misc failure:
...
> Subject: [PATCH] tests: work around portability and clock-skew problems
>
> * tests/misc/ls-misc (push_ls_colors): Don't assume LS_COLORS
> is set.  This part of the fix is by Jim Meyering.
> (sl-dangle2, sl-dangle3, sl-dangle4, sl-dangle5): Don't assume
> that newly-created files will have time stamps in the past.  They
> might not, due to clock skew, if the file systems are remote.

Thanks!
I've pushed that.

Previous Next

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