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. [EMAIL PROTECTED] (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 _______________________________________________ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils