mirror of
git://git.sv.gnu.org/coreutils.git
synced 2026-03-11 23:45:15 +02:00
eb7841426c
I ran into this problem when attempting to recursively remove a directory in a filesystem on flaky hardware. Although the underlying readdir syscall failed with errno == EIO, rm issued no diagnostic about the I/O error. Without this patch I see this behavior: $ rm -fr baddir rm: cannot remove 'baddir': Directory not empty $ rm -ir baddir rm: descend into directory 'baddir'? y rm: remove directory 'baddir'? y rm: cannot remove 'baddir': Directory not empty With this patch I see the following behavior, which lets the user know about the I/O error when rm tries to read baddir's directory entries: $ rm -fr baddir rm: cannot remove 'baddir': Input/output error $ rm -ir baddir rm: cannot remove 'baddir': Input/output error * src/remove.c (Ternary): Remove. All uses removed. (get_dir_status): New static function. (prompt): Last arg is now directory status, not ternary. Return RM_USER_ACCEPTED if user explicitly accepted. All uses changed. Report any significant error in directory status right away. (prompt, rm_fts): Use get_dir_status to get directory status lazily. (excise): Treat any FTS_DNR errno as being more descriptive, not just EPERM and EACCESS. For example, EIO is more descriptive. (rm_fts): Distinguish more clearly between explicit and implied user OK. * src/remove.h (RM_USER_ACCEPTED): New constant. (VALID_STATUS): Treat it as valid. * src/system.h (is_empty_dir): Remove, replacing with ... (directory_status): ... this more-general function. All uses changed. Avoid undefined behavior of looking at a non-null readdir pointer after corresponding closedir. * tests/rm/rm-readdir-fail.sh: Adjust test of internals to match current behavior.