bug-coreutils
[Top][All Lists]
Advanced

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

Re: Darwin HFS+ bug


From: Jim Meyering
Subject: Re: Darwin HFS+ bug
Date: Tue, 26 Sep 2006 21:29:39 +0200

Bruno Haible <address@hidden> wrote:

> mwoehlke wrote:
>> I am also noticing that
>> after making coreutils (and some other packages, I think bash was one),
>> to remove the directory, I have to 'rm -rf coreutils-5.97' as many as
>> four times before it fully goes away. Odd that just doing it several
>> times in succession works, though.
>
> Seen that also quite often on Darwin-7.9.0 (MacOS X 10.3.9).
> It occurs in two different flavours:
>
>   - When a directory has many entries, you "rm -rf" it, rm complains
>     that it couldn't remove everything. Wait ca. 30 seconds, retry.
>     After a few times, it finally succeeds.
>
>   - When a directory has hard links created through NFS or SMBFS.
>     (Such as doing "make install" of GCC: it creates a hard link
>     between bin/gcc and bin/cc, and between bin/g++ and bin/c++).
>     Here, "rm -rf" fails, but waiting doesn't help, and rm of one of these
>     always fails. What appears to work, is to "rm" the other one, or
>     to move one of the files to a different directory using "mv" and then
>     retry "rm -rf".

That appears to be due to a bug in Darwin-7.x's readdir.
This constant (in remove.c), which I thought was conservative,
since I chose it to be 54 less than the previous known minimum,
appears to be a little too large after all.

  /* 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
    };




reply via email to

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