|
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
[Prev in Thread] | Current Thread | [Next in Thread] |