[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Eric Blake
Subject: bug#9813: rm -rf calls rmdir() prior to close(), which can fail
Date: Thu, 20 Oct 2011 18:06:03 -0600
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv: Gecko/20110928 Fedora/3.1.15-1.fc14 Lightning/1.0b3pre Mnenhy/0.8.4 Thunderbird/3.1.15

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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]