Re: Correct semantics in rm -rf ?

[Jim Meyering]

shailesh jain wrote:
> On Wed, Aug 26, 2009 at 2:36 AM, Jim Meyering <address@hidden> 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.