On 2007-03-06 15:17:07 +0100, Jim Meyering wrote: > Such "remembering" would be prohibitively expensive, in general.
I don't see why. In fact, it isn't necessarily useful to remember anything. When rm attempts to remove a file in a recurse phase, no errors should be reported if the file doesn't exist. > It sounds like your client NFS implementation's cache is not coherent, This is a feature of NFS. A full-synchronized NFS implementation would be too slow (if not impossible, due to race conditions). Even disabling attribute caching only (with the noac option), makes some NFS accesses very slow. > at least in some respect. The client has successfully unlinked a file, > yet after a rewinddir, a subsequent readdir gets the same name; that > suggests the dir entry is out of date: it doesn't reflect operations > the client itself has marshaled. This is not exactly true. At this time, the dir entry may still exist on the server side. Then there's the question of whether dir operations should reflect what is on the server or on the client. The observed behavior is bad, but I wonder if this can be called a bug or if there is any reason to behave like that (BTW, this is a 2.6.18 Linux kernel). Moreover even on a fully-compliant POSIX system, it is possible to get a dir entry for some file, but when rm tries to unlink the file, it no longer exists (there's a race condition here). -- Vincent Lefèvre <[EMAIL PROTECTED]> - Web: <http://www.vinc17.org/> 100% accessible validated (X)HTML - Blog: <http://www.vinc17.org/blog/> Work: CR INRIA - computer arithmetic / Arenaire project (LIP, ENS-Lyon) _______________________________________________ Bug-coreutils mailing list [email protected] http://lists.gnu.org/mailman/listinfo/bug-coreutils
