Weird CLI behaviour.

[Colin Watson]

On Mon, Feb 10, 2020 at 04:09:03PM -0500, Ken D'Ambrosio wrote:
> Bottom line: there's a /tmp/foobar that the system generally knows
> about, and there's a /tmp/foobar that *only my bash session* knows
> about.

Sort of; at this point the bash process in question still has a
reference to "." (its current directory), but it doesn't know about
"/tmp/foobar" as such.  (Similarly, it's possible for a directory to be
renamed but for processes that have them as their current working
directory to have an out-of-date idea of what a path to that directory
might be.)

> This is not a bug, but is expected behavior for
> deleted-but-not-reaped files/directories.

While most of this is expected behaviour, the part that I'd still argue
is a bug is that ls doesn't issue an error message.  In principle it
should be in a position to tell that there's a problem: you can tell
this by running "strace ls", in which case you'll see something like
this near the end:

  openat(AT_FDCWD, ".", O_RDONLY|O_NONBLOCK|O_CLOEXEC|O_DIRECTORY) = 3
  fstat(3, {st_mode=S_IFDIR|0755, st_size=0, ...}) = 0
  getdents(3, 0x5629cd051640, 32768)      = -1 ENOENT (No such file or directory)

It's not entirely *easy* for ls to figure this out, because what it
actually calls is the readdir() C library function, and (according to
glibc's source code) that's bound by a POSIX requirement that this
condition be treated as if this error just means that readdir() has
reached the end of the directory, so readdir() just returns NULL with no
errno set (I confirmed this with gdb).  However, I think that ls could
still observe that it didn't even read the usual entries for "." and
".." from the directory and thus the directory must not exist, allowing
it to issue an error message in this case.

-- 
Colin Watson                                       [cjwatson at ubuntu.com]