bug#43497: ls exit status on removed directory

[Paul Eggert]

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 
 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 
:


  /* 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 
.

bug#43497: ls exit status on removed directory

[Pádraig Brady]

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

bug#43497: ls exit status on removed directory

[Philip Rowlands]

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?