Weird CLI behaviour.

[Owen Thomas]

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.

On Tue, 11 Feb 2020 at 11:24, Colin Watson <cjwatson at ubuntu.com> wrote:

> 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]
>
> --
> ubuntu-users mailing list
> ubuntu-users at lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/ubuntu-users
>


-- 
I'll cut your code at an intensity and from a place of my own choosing.
Clique Space(TM). Anima ex machina.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/ubuntu-users/attachments/20200211/26dc0b39/attachment.html>