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

2011-10-24 Thread Eric Blake
On 10/24/2011 02:58 AM, Jim Meyering wrote: ** Bug fixes + rm -rf DIR would fail with "Device or resource busy" on Cygwin with NWFS + and NcFsd file systems. This did not affect Unix/Linux-based kernels. + [bug introduced in coreutils-7.0, when rm began using fts] rm didn't use fts() unt

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

2011-10-24 Thread Jim Meyering
Jim Meyering wrote: >> Here is the patch that I expect to push tomorrow: ... > I've fixed/improved the ChangeLog/commit-log: > > Subject: [PATCH] fts: close parent dir FD before returning from > post-traversal fts_read > > The problem: the fts-using "mkdir -p A/B; rm -rf A" would attempt to > unli

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

2011-10-24 Thread Jim Meyering
Jim Meyering wrote: ... > Here is the patch that I expect to push tomorrow: > > Subject: [PATCH] fts: close parent dir FD before returning from > post-traversal fts_read > > The problem: the fts-using "rm -rf A/B/" would attempt to unlink A, > while a file descriptor open on A remained. This is s

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

2011-10-23 Thread Jim Meyering
Eric Blake wrote: > POSIX is clear that attempts to rmdir() a directory that still has > open descriptors may fail. Of course, on Linux, this (rather > limiting) restriction is not present, so we don't notice it; but on > Cygwin, there are certain file systems where this is a real problem, > such

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

2011-10-20 Thread Paul Eggert
On 10/20/11 17:06, Eric Blake wrote: >> 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 I don't see why NFSv3 or v3 would be different. I just tried your test case with an NFSv3 mount (RHEL 5.7

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

2011-10-20 Thread Eric Blake
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-s

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

2011-10-20 Thread Eric Blake
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 ha

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

2011-10-20 Thread Paul Eggert
On 10/20/11 12:57, Eric Blake wrote: > That's because it's a shall fail, not a may fail error: > > [EBUSY] > The directory to be removed is currently in use by the system > or some process and the implementation considers this to be an error. But "in use by" does not mean "accessed by an open fil

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

2011-10-20 Thread Eric Blake
On 10/20/2011 01:47 PM, Paul Eggert wrote: On 10/20/11 10:38, Eric Blake wrote: POSIX is clear that attempts to rmdir() a directory that still has open descriptors may fail. Hmm, that's news to me. And on the contrary, the spec

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

2011-10-20 Thread Paul Eggert
On 10/20/11 10:38, Eric Blake wrote: > POSIX is clear that attempts to rmdir() a directory that still has open > descriptors may fail. Hmm, that's news to me. And on the contrary, the spec explicitly talks about what rmdir()

rm -rf calls rmdir() prior to close(), which can fail

2011-10-20 Thread Eric Blake
POSIX is clear that attempts to rmdir() a directory that still has open descriptors may fail. Of course, on Linux, this (rather limiting) restriction is not present, so we don't notice it; but on Cygwin, there are certain file systems where this is a real problem, such as in this thread: http