Re: rm -r sometimes produces errors under NFS

[Paul Eggert]

Jim Meyering <address@hidden> 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....)