[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: rm -r recursion failure

From: Jim Meyering
Subject: Re: rm -r recursion failure
Date: Tue, 12 Apr 2005 19:11:50 +0200

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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]