[Top][All Lists]

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

bug#43497: ls exit status on removed directory

From: Paul Eggert
Subject: bug#43497: ls exit status on removed directory
Date: Mon, 21 Sep 2020 01:52:14 -0700
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0

On 9/18/20 4:15 PM, Philip Rowlands wrote:

$ mkdir /tmp/abc
$ cd /tmp/abc
$ rmdir /tmp/abc
$ ls

What happened:
no output, successful exit status

What was expected:
no output, unsuccessful exit status

POSIX says that the rmdir command is supposed to behave like the rmdir syscall. For the syscall, POSIX allows either of the two behaviors you mention, as <https://pubs.opengroup.org/onlinepubs/9699919799/functions/rmdir.html> says that if the rmdir syscall's argument is "the current working directory of any process, it is unspecified whether the function succeeds, or whether it shall fail and set errno to [EBUSY]". The Linux kernel rmdir syscall succeeds, so coreutils rmdir succeeds.

ls tried to list the contents of . but failed to do so, at least on Linux:
getdents(3, 0x55e10c419cf0, 32768)      = -1 ENOENT (No such file or directory)

ls doesn't use getdents directly; it uses the readdir function of the GNU C library, which specifically tests for this situation and sets errno to 0, with this comment at <https://sourceware.org/git/?p=glibc.git;a=blob;f=sysdeps/posix/readdir.c;h=b36278b5f486eb43aeec2cb76138288e39cd56cd;hb=HEAD#l68>:

/* On some systems getdents fails with ENOENT when the open directory has been rmdir'd already. POSIX.1
                 requires that we treat this condition like normal EOF.  */

It's not clear to me that this comment is correct for current POSIX, but anyway this is a matter for the GNU C library not for coreutils ls, so if you think there's a bug there I suggest filing a glibc bug report <https://sourceware.org/glibc/wiki/FilingBugs>.

reply via email to

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