Re: Correct semantics in rm -rf ?

[Jim Meyering]

shailesh jain wrote:
> rm -rf does following (highly simplified)
> ----
>
> remove_cwd_entries() {
>
>    // Check if dirp is empty ...
>   readdir();
> }
>
> remove_dir() {
> while(1) {
>
>      remove_cwd_entries();
>
>     // Get the fd of directory
>     fd = open();
>
>     // Unlink empty_dir
>     unlinkat();
>
>     dirp = fdopendir(fd);
>
> }
> }
> -----
>
> open() call on directory goes to the VFS layer that is when the directory
> stream gets attached to it. Any subsequent modifications made to the
> directory like unlinkat() may or may not be reflected in readdir() calls.
> (Note: fdopendir() call does not goto underlying filesystem... ). So the
> code in remove_cwd_entries() that checks if directory is empty may find the
> deleted directory entry.... Isn't this code relying upon incorrect semantics
> ?

Thanks for the report.

I guess you're worried that rm -rf would perform extra work
in attempting to remove those already-removed entries again?
If this is really a problem, I'd be concerned with a user-visible
consequence, like rm -ri prompting twice about the same name.

There may well be file system implementations for which rm
misbehaves, but so far, no one has reported such a problem.

> I see that local filesystems tend to work even with this behavior but
> network file systems that would bring in entire directory contents on open()
> will not work ?

If you can demonstrate an actual failure, or even that rm is
merely performing unnecessary unlinkat calls, please provide details.