<div dir="ltr">Hi I am the OP on this thread, and I agree with Colin and others that the CLI should better inform the user (or even a script if one is running) when the situation occurs. I apologise that I hadn't risen a bug for this problem, but am indeed thankful that others appear to be taking an interest in it.<br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, 11 Feb 2020 at 11:24, Colin Watson <<a href="mailto:cjwatson@ubuntu.com">cjwatson@ubuntu.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Mon, Feb 10, 2020 at 04:09:03PM -0500, Ken D'Ambrosio wrote:<br>
> Bottom line: there's a /tmp/foobar that the system generally knows<br>
> about, and there's a /tmp/foobar that *only my bash session* knows<br>
> about.<br>
<br>
Sort of; at this point the bash process in question still has a<br>
reference to "." (its current directory), but it doesn't know about<br>
"/tmp/foobar" as such.  (Similarly, it's possible for a directory to be<br>
renamed but for processes that have them as their current working<br>
directory to have an out-of-date idea of what a path to that directory<br>
might be.)<br>
<br>
> This is not a bug, but is expected behavior for<br>
> deleted-but-not-reaped files/directories.<br>
<br>
While most of this is expected behaviour, the part that I'd still argue<br>
is a bug is that ls doesn't issue an error message.  In principle it<br>
should be in a position to tell that there's a problem: you can tell<br>
this by running "strace ls", in which case you'll see something like<br>
this near the end:<br>
<br>
  openat(AT_FDCWD, ".", O_RDONLY|O_NONBLOCK|O_CLOEXEC|O_DIRECTORY) = 3<br>
  fstat(3, {st_mode=S_IFDIR|0755, st_size=0, ...}) = 0<br>
  getdents(3, 0x5629cd051640, 32768)      = -1 ENOENT (No such file or directory)<br>
<br>
It's not entirely *easy* for ls to figure this out, because what it<br>
actually calls is the readdir() C library function, and (according to<br>
glibc's source code) that's bound by a POSIX requirement that this<br>
condition be treated as if this error just means that readdir() has<br>
reached the end of the directory, so readdir() just returns NULL with no<br>
errno set (I confirmed this with gdb).  However, I think that ls could<br>
still observe that it didn't even read the usual entries for "." and<br>
".." from the directory and thus the directory must not exist, allowing<br>
it to issue an error message in this case.<br>
<br>
-- <br>
Colin Watson                                       [<a href="mailto:cjwatson@ubuntu.com" target="_blank">cjwatson@ubuntu.com</a>]<br>
<br>
-- <br>
ubuntu-users mailing list<br>
<a href="mailto:ubuntu-users@lists.ubuntu.com" target="_blank">ubuntu-users@lists.ubuntu.com</a><br>
Modify settings or unsubscribe at: <a href="https://lists.ubuntu.com/mailman/listinfo/ubuntu-users" rel="noreferrer" target="_blank">https://lists.ubuntu.com/mailman/listinfo/ubuntu-users</a><br>
</blockquote></div><br clear="all"><br>-- <br><div dir="ltr" class="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><span style="font-size:12.8px">I'll cut your code at an intensity and from a place of my own choosing.</span></div><div><span style="font-size:12.8px">Clique Space(TM). Anima ex machina.</span><br></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div>