Jim Meyering <[EMAIL PROTECTED]> writes:
> If I were to make such a change, it is quite likely
> that it would cause a real unlink failure not to be
> reported, and *that* would be serious.
Doesn't this wart come from the hack to work around a readdir bug in
MacOS? It sounds a bit like the tail wagging the dog if a MacOS
workaround causes infelicitious behavior in a pure GNU/Linux
environment.
One thing that jumps out at me is that test.log looks like this:
Read the directory, removing files as we go.
getdents64(4, /* 15 entries */, 8192) = 472
lstat("/proc/self/fd/4/config.h.in", {st_mode=S_IFREG|0644, st_size=27828,
...}) = 0
access("test/config.h.in", W_OK) = 0
unlink("/proc/self/fd/4/config.h.in") = 0
...
getdents64(4, /* 0 entries */, 8192) = 0
Rewind the directory.
lseek(4, 0, SEEK_SET) = 0
Read the directory again, removing files as we go again.
getdents64(4, /* 15 entries */, 8192) = 472
lstat("/proc/self/fd/4/config.h.in", {st_mode=S_IFREG|0644, st_size=27828,
...}) = 0
access("test/config.h.in", W_OK) = -1 ESTALE (Stale NFS file handle)
unlink("/proc/self/fd/4/config.h.in") = -1 ENOENT (No such file or
directory)
open(".", O_RDONLY) = 3
fchdir(4) = 0
unlink("config.h.in") = -1 ENOENT (No such file or
directory)
fchdir(3) = 0
close(3) = 0
write(2, "rm: ", 4) = 4
write(2, "cannot remove `test/config.h.in\'", 32) = 32
That ESTALE result, if we propagated it to the caller, could be a hint
that our bug-workaround is causing trouble, and could cause 'rm' to
suppress the diagnostic.
A simpler possibility would be to rip out the bug-workaround entirely,
at least on non-MacOS hosts. (After all, once your NFS server is
buggy all bets are off....)
_______________________________________________
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils
