shailesh jain wrote: > On Wed, Aug 26, 2009 at 2:36 AM, Jim Meyering <[email protected]> wrote: ... >> If you can demonstrate an actual failure, or even that rm is >> merely performing unnecessary unlinkat calls, please provide details. > > Thanks for consideration. I will describe how 'rm -rf parent' fails: > --- > mkdir parent > cd parent > mkdir Child > cd .. > cd .. ... > > Now, unlinkat() will delete child directory on unlinkat() and then do dirp = > fdopendir(parent_fd). Then it will perform readdir() calls on parent just to > find out that 'Child' directory is still present and it will mark 'Child' > directory is unremovable... (and I think it subsequently tries to remove > 'Child' and doesn't find 'Child' and terminates with ENOENT when I use rm > -riv) > > I read from the posix semantics that fdopendir() should behave same as > opendir(), however given that the VFS layer and the underlying filesystem > cannot distinguish between open() and opendir(), I do not see any reasonable > way to do that. Thus relying on readdir() to reflect updates made by > unlinkat() is broken (although local file systems tend to reflect this very > well).
I understood your theoretical description the first time. Please provide details showing precisely how GNU rm is misbehaving. Either step through with a debugger or show the system calls e.g., from strace: Please describe your file system (client and server system types, if they're different) and give the output of your "strace -o log rm -riv parent" command as well as the "log" file that creates. If rm fails in a way that is contrary to POSIX, we'd all like to know. Also, please be sure to use rm from coreutils-7.5.
