summaryrefslogtreecommitdiff
path: root/ChangeLog
diff options
context:
space:
mode:
authorJim Meyering <jim@meyering.net>2005-05-13 07:39:50 +0000
committerJim Meyering <jim@meyering.net>2005-05-13 07:39:50 +0000
commitc176e344680ba28bdaa228b60fbe1312da3b8b9f (patch)
tree0274f53abad95e78b5607103f64eca9b2be3b2c8 /ChangeLog
parentbe5f7b36a1ba5868b2ba29424b974c70fb378ada (diff)
downloadcoreutils-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