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