GNU bug report logs -
#43497
ls exit status on removed directory
Previous Next
To reply to this bug, email your comments to 43497 AT debbugs.gnu.org.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
bug-coreutils <at> gnu.org
:
bug#43497
; Package
coreutils
.
(Fri, 18 Sep 2020 23:17:02 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
"Philip Rowlands" <phr+coreutils <at> dimebar.com>
:
New bug report received and forwarded. Copy sent to
bug-coreutils <at> gnu.org
.
(Fri, 18 Sep 2020 23:17:02 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
Steps to reproduce:
$ 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
ls tried to list the contents of . but failed to do so, at least on Linux:
open(".", O_RDONLY|O_NONBLOCK|O_DIRECTORY|O_CLOEXEC) = 3
getdents(3, 0x55e10c419cf0, 32768) = -1 ENOENT (No such file or directory)
Although "stat ." and "ls -ld ." still work on the removed directory, should "ls ." report success even though the getdents syscall fails?
Information forwarded
to
bug-coreutils <at> gnu.org
:
bug#43497
; Package
coreutils
.
(Sat, 19 Sep 2020 12:51:02 GMT)
Full text and
rfc822 format available.
Message #8 received at 43497 <at> debbugs.gnu.org (full text, mbox):
On 19/09/2020 00:15, Philip Rowlands wrote:
> Steps to reproduce:
>
> $ 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
>
> ls tried to list the contents of . but failed to do so, at least on Linux:
> open(".", O_RDONLY|O_NONBLOCK|O_DIRECTORY|O_CLOEXEC) = 3
> getdents(3, 0x55e10c419cf0, 32768) = -1 ENOENT (No such file or directory)
>
> Although "stat ." and "ls -ld ." still work on the removed directory, should "ls ." report success even though the getdents syscall fails?
What you expect was released as part of v8.32:
https://git.sv.gnu.org/gitweb/?p=coreutils.git;a=commitdiff;h=v8.31-88-g05a99f7d7
though current trunk (and Fedora at least), have reverted to the original behavior:
https://git.sv.gnu.org/gitweb/?p=coreutils.git;a=commitdiff;h=v8.32-2-g10fcb97bd
cheers,
Pádraig
Information forwarded
to
bug-coreutils <at> gnu.org
:
bug#43497
; Package
coreutils
.
(Mon, 21 Sep 2020 08:53:01 GMT)
Full text and
rfc822 format available.
Message #11 received at 43497 <at> debbugs.gnu.org (full text, mbox):
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:
> open(".", O_RDONLY|O_NONBLOCK|O_DIRECTORY|O_CLOEXEC) = 3
> 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>.
This bug report was last modified 4 years and 46 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.