Re: rm -r recursion failure

[Jim Meyering]

This is probably due to a bug in how readdir works on your system.
Currently coreutils has a configure-time run-test that detects whether
rm's relatively expensive work-around code is required.  But if that test
runs only on a file system that does not exhibit the bug, then rm is built
without the work-around code.  That's probably what happened in your case.

The alternative design would be to include in rm.c (remove.c actually)
itself code to detect the problem and work around it, even on systems
that don't ever exhibit the bug.  I was reluctant to impose that cost
on every system with only POSIX-compliant readdir implementations.

I suggest that you configure/build coreutils in a working directory
that is NFS-mounted like the one that exhibited the problem.  Then you
should end up with a rm binary that works there.  FYI, to check for
this configure-time test result, look for gl_cv_func_working_readdir
in config.h after you've run ./configure.  If it is equal to `no',
then your resulting `rm' binary will have the required work-around code.

If that doesn't help, please let me know, and we'll dig deeper.

address@hidden (John W. MacDonald) wrote:
> This report is very similar to earlier ones involving recursion failure using
> 'rm -r'
> on directories on nfs mounted volumes. (see
> http://lists.gnu.org/archive/html/bug-coreutils/2004-03/msg00016.html). In 
> this case:
>
> client: RedHat Enterprise WS 3.x, (kernel 2.4.21-15.0.4.ELsmp)
>
> server: Apple Xserve OS X server v.10.3.8; filesystems: HFS+ (journaled) 
> [tested