bug#9813: rm -rf calls rmdir() prior to close(), which can fail

[Eric Blake]

On 10/20/2011 05:46 PM, Paul Eggert wrote:
> > It's more than just cygwin.
>
> So far, I've seen only Cygwin mentioned.
> Where does it happen in a typical GNUish environment?

Try the same exercise using NFSv2 or NFSv3 mounts (NFSv4 is getting 
closer to POSIX compliance, but I don't know if it will handle this any 
better).  I suspect that it would be possible to find a testcase under 
Linux and Solaris clients using a less-than-stellar remote NFS server 
that reproduces this issue, at least on any setup where you would also 
see a failure in unlink()ing a regular file with open fds (rmdir() a 
directory with open handles is conceptually no different than unlink()).

> This isn't just a coreutils issue: I expect that it'll occur
> many programs that do the equivalent of "rm -fr".

Many programs that do the equivalent of "rm -fr" are using more naive 
algorithms (like coreutils 7.0 rm did) that do not involve fts() and 
unlinkat(), and thus do not hit the problem in the first place, because 
they aren't leaving the directory fd open during the rmdir().  But you 
are right that an strace of 'find a -delete' shows that find suffers 
from the same issue, while 'oldfind a -delete' is immune; again a 
problem where the difference is the use of gnulib's fts().

Maybe we need to ask for clarification from the Austin Group on how much 
of Window's default behavior should affect POSIX compliance (that 
behavior being that a directory is busy if any process has it as a 
current working directory or if any fd is open on the directory).

--
Eric Blake   address@hidden    +1-801-349-2682
Libvirt virtualization library http://libvirt.org