diff options
author | Jim Meyering <jim@meyering.net> | 2005-05-13 07:39:50 +0000 |
---|---|---|
committer | Jim Meyering <jim@meyering.net> | 2005-05-13 07:39:50 +0000 |
commit | c176e344680ba28bdaa228b60fbe1312da3b8b9f (patch) | |
tree | 0274f53abad95e78b5607103f64eca9b2be3b2c8 /ChangeLog | |
parent | be5f7b36a1ba5868b2ba29424b974c70fb378ada (diff) | |
download | coreutils-c176e344680ba28bdaa228b60fbe1312da3b8b9f.tar.xz |
* NEWS: `rm -r' now removes all of the files it should, even on
systems with a buggy readdir affecting file systems inaccessible
at configure time.
In some unusual circumstances `rm -r' would fail to remove --
or even consider -- all entries in a directory with more than 254
(SunOS) or 338 (Darwin) entries. This could cause trouble even on
other types of systems when using an affected file system via e.g.,
NFS. The underlying cause was a bug in readdir on those systems.
Coreutils-5.2.1 and earlier used a configure-time test designed
to detect precisely those problem systems, but it would detect
the problem and enable remove.c's work-around code only when its
configure-time test was run on a losing file system. Obviously,
it couldn't detect a problem if the offending file system wasn't
tested or even mounted at coreutils configure time. Now, rm itself
performs a minimal-cost run-time test to detect the problem.
(CONSECUTIVE_READDIR_UNLINK_THRESHOLD): Define.
(remove_cwd_entries): When readdir returns NULL for a directory from
which we've removed more than CONSECUTIVE_READDIR_UNLINK_THRESHOLD
entries, call rewinddir and then resume the readdir/unlink loop.
(UNLINK_CAN_UNLINK_DIRS): Rename from ROOT_CAN_UNLINK_DIRS.
Diffstat (limited to 'ChangeLog')
0 files changed, 0 insertions, 0 deletions