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 ebl...@redhat.com +1-801-349-2682
Libvirt virtualization library http://libvirt.org
