[Top][All Lists]
[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
};
- Re: [bug-gnulib] Re: coreutils-6.2: various runtime problems on Darwin-8.7.0 HFS+ (including attachment this time), (continued)
- GNU rm now works around Darwin 0.7.9 (MaxOS X 10.3.9) readdir bug, Jim Meyering, 2006/09/29
- Re: GNU rm now works around Darwin 0.7.9 (MaxOS X 10.3.9) readdir bug, Bruno Haible, 2006/09/29
- Re: GNU rm now works around Darwin 0.7.9 (MaxOS X 10.3.9) readdir bug, Jim Meyering, 2006/09/29
- Re: [bug-gnulib] Re: GNU rm now works around Darwin 0.7.9 (MaxOS X 10.3.9) readdir bug, Bruno Haible, 2006/09/29
- really fixed, this time [Re: GNU rm now works around Darwin 0.7.9 (MaxOS X 10.3.9) readdir bug, Jim Meyering, 2006/09/29
- Re: Darwin HFS+ bug, Bruno Haible, 2006/09/26
- Re: Darwin HFS+ bug,
Jim Meyering <=
- Re: Darwin HFS+ bug, Paul Eggert, 2006/09/26
- Re: Darwin HFS+ bug, Jim Meyering, 2006/09/27
- Message not available
- Re: Darwin HFS+ bug, Paul Eggert, 2006/09/27
- Re: coreutils-6.2: various runtime problems on Darwin-8.7.0 HFS+ (including attachment this time), Jim Meyering, 2006/09/26
- Message not available
- Re: now getting a build error with coreutils-cvs (Re: coreutils-6.2: various runtime problems on Darwin-8.7.0 HFS+ (including attachment this time)), Jim Meyering, 2006/09/26
- Message not available
- Re: coreutils-cvs build error fixed (Re: now getting a build error with coreutils-cvs (Re: coreutils-6.2: various runtime problems on Darwin-8.7.0 HFS+ (including attachment this time))), Paul Eggert, 2006/09/27
- Message not available
- OT: latest stable version not recommended (was: coreutils-cvs build error fixed), Bob Proulx, 2006/09/27
- Message not available
- Re: OT: latest stable version not recommended, Paul Eggert, 2006/09/27
- Message not available
- Re: cvs build error with Apple-installed tools (Re: OT: latest stable version not recommended), Paul Eggert, 2006/09/27
- Message not available
- Re: cvs build error with Apple-installed tools (Re: OT: latest stable version not recommended), Paul Eggert, 2006/09/28