mwoehlke <[EMAIL PROTECTED]> wrote: ... > Did you try with 5.97? I haven't tried 6.2 yet (will try to do that
No, since rm in that release is so different, and since I don't plan to make a 5.98 release. > soon)... Um, actually, I am probably not going to try until someone can > tell me how the *&($ to test the exit code of 'make check' after I've > piped it through 'tee' :-) - tips would be most welcome! > > Easiest test is on coreutils itself... > > $ uname -srvmpio > Darwin 7.9.0 Darwin Kernel Version 7.9.0: Wed Mar 30 20:11:17 PST 2005; > root:xnu/xnu-517.12.7.obj~1/RELEASE_PPC Power Macintosh powerpc > RackMac3,1 Darwin > $ rm --version > rm (GNU coreutils) 5.97 > Copyright (C) 2006 Free Software Foundation, Inc. > This is free software. You may redistribute copies of it under the terms of > the GNU General Public License <http://www.gnu.org/licenses/gpl.html>. > There is NO WARRANTY, to the extent permitted by law. > > Written by Paul Rubin, David MacKenzie, Richard Stallman, and Jim Meyering. > $ ls coreutils-5.97 > ls: coreutils-5.97: No such file or directory > $ tar xzf coreutils-5.97.tar.gz > $ find coreutils-5.97/ | wc -l > 2788 > $ rm -rf coreutils-5.97 > rm: cannot remove directory `coreutils-5.97/m4': Directory not empty > rm: cannot remove directory `coreutils-5.97/lib': Di0rectory not empty > $ find coreutils-5.97/ | wc -l > 173 > $ rm -rf coreutils-5.97 > $ find coreutils-5.97/ | wc -l > find: coreutils-5.97/: No such file or directory > 0 > $ Thanks. That's probably all I needed. >From those numbers and the number of files in lib and m4, I deduce that your system's readdir is mistakenly returning NULL when there are around 190 entries in a directory. Would you please try this, to confirm the theory: #!/bin/bash for i in $(seq 150 200); do echo i=$i mkdir b; (cd b; mkdir $(seq $i) ); Rm -r b || { echo bug at i=$i; break; } done That should find the minimum number of entries for which rm fails. Once you find that number, say 190, change the enum in your copy of coreutils' src/remove.c that looks like this: /* This is the maximum number of consecutive readdir/unlink calls that can be made (with no intervening rewinddir or closedir/opendir) before triggering a bug that makes readdir return NULL even though some directory entries have not been processed. The bug afflicts SunOS's readdir when applied to ufs file systems and Darwin 6.5's (and OSX v.10.3.8's) HFS+. This maximum is conservative in that demonstrating the problem seems to require a directory containing at least 254 deletable entries (which doesn't count . and ..), so we could conceivably increase the maximum value to 254. */ enum { CONSECUTIVE_READDIR_UNLINK_THRESHOLD = 200 }; to use the number that is one smaller than the one you found: CONSECUTIVE_READDIR_UNLINK_THRESHOLD = 189 Then recompile, and "rm -r" should work. Please let us know.
