bug-gnulib
[Top][All Lists]
Advanced

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

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


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

On 10/20/2011 06:06 PM, Eric Blake wrote:
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()).

Also, notice that the POSIX requirement on unlink() is that ETXTBSY is a may fail (a file is currently being executed by some other process), but that EBUSY is a shall fail, with the same wording as for rmdir(), namely:

[EBUSY]
The file named by the path argument cannot be unlinked because it is being used by the system or another process and the implementation considers this an error.

This "shall fail" EBUSY is _how_ NFS justifies their behavior of failing to unlink files with open fds, even though I agree with you that it flies in the face of traditional Unix semantics, and explains why many GNU programs have already made efforts to ensure that all fds to a file are closed before attempting unlink/rmdir.

--
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]