Re: rm -r sometimes produces errors under NFS

[Vincent Lefevre]

On 2007-03-08 00:14:06 +0100, Jim Meyering wrote:
> If you want to discuss further whether rm -r should ignore ENOENT
> unconditionally, I suggest that you raise the issue with the people
> who work on the POSIX standard (use the austin-group-l mailing list;
> subscribe at http://www.opengroup.org/austin/lists.html).  If you can
> convince them that you're right, then you'll have a much easier time
> convincing me to change the corresponding bits in coreutils.

I've asked the question there. I've only had one answer for the moment
on this subject. It says that the implementation can choose either to
write or diagnostic or not. So, there would be nothing wrong to avoid
the diagnostic in this case and would make rm run nicer under NFS and
behave more consistently.

Moreover, whatever happens, the rmdir() shall be called. The current
rm implementation doesn't.

> > But POSIX just says "For each entry contained in file". It doesn't
> > say "While there is an entry in file". With rewinddir, you're doing
> > "While there is an entry in file", and "rm -r" can loop indefinitely
> > (depending on the other processes).
> 
> Precisely.
> That is how I chose (and choose) to implement rm.

The answer I had in the austin-group-l said: "I think that
implementations would be allowed to call rewinddir() after deleting
every single directory entry, provided they don't get stuck in a
loop."

> Certainly, there are contrived scenarios in which GNU rm will not
> terminate (you'd need multiple concurrent processes creating entries
> in a directory that rm is removing, since unlinking is faster than
> creation) but one can also argue that rm is doing what the user
> wants in that case.

As a user, I particularly expect rm to behave consistently. Why does
rm call rewinddir under some conditions only? For instance, if I
execute "rm -ri dir", and answer "no" to a question for one of the
files, then it doesn't call rewinddir.

> >> If any unlink fails, rm does not try to call rmdir on any
> >> parent directory.  If your case (all unlinks failed with
> >> ENOENT) were common, it might be worth handling it by attempting
> >> the rmdir if that's the only type of failure.
> >
> > There is another case. Say, you have two shells 1 and 2:
> >
> > 1> mkdir dir
> > 1> touch dir/a
> > 1> touch dir/b
> > 1> rm -ri dir
> > rm: descend into directory `dir'? y
> > rm: remove regular empty file `dir/a'? n
> > rm: remove regular empty file `dir/b'?
> >
> > Before answering, in the second shell:
> >
> > 2> rm dir/a
> >
> > Then back to the first shell:
> >
> > rm: remove regular empty file `dir/b'? y
> > 1> test -d dir && echo OK
> > OK
> >
> > IMHO, this is incorrect. Step 4 just says: "If the current file is a
> > directory, rm shall perform actions equivalent to the rmdir() function
> > defined in the System Interfaces volume of IEEE Std 1003.1-2001 called
> > with a pathname of the current file used as the path argument." Nothing
> > about the answers for the files contained in the directory.
> 
> I understand your desire,

This is not only my desire, but this is what POSIX requires. And this
is confirmed in the answer I got in austin-group-l.

> but consider this case:
> Given a hierarchy d/d/d/d/d/d/d/F where F cannot be removed,
> what should "rm -fr d" report?
> 
> a single line diagnostic, as it currently does:
> 
>   rm: cannot remove `d/d/d/d/d/d/d/F': Permission denied

But notice that this is different from an ENOENT error. In the case
of an ENOENT error, the directory is empty. but not in the above case.

> or one for every parent directory for which rmdir fails
> with e.g., ENOTEMPTY?
> 
>   rm: cannot remove `d/d/d/d/d/d/d/F': Permission denied
>   rm: cannot remove `d/d/d/d/d/d/d': Directory not empty
>   rm: cannot remove `d/d/d/d/d/d': Directory not empty
>   rm: cannot remove `d/d/d/d/d': Directory not empty
>   rm: cannot remove `d/d/d/d': Directory not empty
>   rm: cannot remove `d/d/d': Directory not empty
>   rm: cannot remove `d/d': Directory not empty
>   rm: cannot remove `d': Directory not empty
> 
> I want the former.  The "Directory not empty" diagnostics are not useful.

Well, the diagnostics you write in case of an ENOENT error are not
useful either.

Moreover you complain about the diagnostics. But what prevents you
from calling rmdir(), as required by POSIX? If you don't like these
diagnostics, then don't write them when rmdir() fails (and IMHO,
the first "Directory not empty" diagnostic is sufficient, as the
other ones can be seen as redundant).

-- 
Vincent Lefèvre <address@hidden> - 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)