readdir and ENOENT error or EOF?

readdir and ENOENT error or EOF?

[Mark Olesen]

There appears to be ambiguity in user documentation for readdir when
it returns NULL and errno is set to ENOENT.

Is this an EOF condition or an actual error that should be handled?

...
/* 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. */
if (bytes < 0 && errno == ENOENT)
bytes = 0;
...
https://code.woboq.org/userspace/glibc/sysdeps/posix/readdir.c.htmlin

Thanks in advance for your time and help on this matter.

Re: readdir and ENOENT error or EOF?

[Florian Weimer]

* Mark Olesen via Libc-alpha:

> There appears to be ambiguity in user documentation for readdir when
> it returns NULL and errno is set to ENOENT.
>
> Is this an EOF condition or an actual error that should be handled?
>
> ...
> /* 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. */
> if (bytes < 0 && errno == ENOENT)
> bytes = 0;
> ...
> https://code.woboq.org/userspace/glibc/sysdeps/posix/readdir.c.htmlin

Note that the Linux implementation is in
sysdeps/unix/sysv/linux/readdir.c, but it has this quirk as well.

I believe this has been copied over from historic times.  In general,
Linux handles this corner case differently.  However, the Linux VFS
layer will pass through ENOENT from file system implementations, so if a
file system implementation generates ENOENT in its readdir
implementation, we might still see ENOENT in userspace.  That's why it's
difficult to remove the check from glibc's readdir implementation.

Thanks,
Florian

Re: readdir and ENOENT error or EOF?

[Mark Olesen]

I apologize for what I posted in libc-alpha. I did not realize the
post actually made it on the list. I reposted it in libc-help.
However, thanks for your answer.

Should ENOENT be handled as an error or is it indeed an EOF condition?



On Thu, Jun 17, 2021 at 1:07 AM Florian Weimer <fweimer@redhat.com> wrote:
>
> * Mark Olesen via Libc-alpha:
>
> > There appears to be ambiguity in user documentation for readdir when
> > it returns NULL and errno is set to ENOENT.
> >
> > Is this an EOF condition or an actual error that should be handled?
> >
> > ...
> > /* 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. */
> > if (bytes < 0 && errno == ENOENT)
> > bytes = 0;
> > ...
> > https://code.woboq.org/userspace/glibc/sysdeps/posix/readdir.c.htmlin
>
> Note that the Linux implementation is in
> sysdeps/unix/sysv/linux/readdir.c, but it has this quirk as well.
>
> I believe this has been copied over from historic times.  In general,
> Linux handles this corner case differently.  However, the Linux VFS
> layer will pass through ENOENT from file system implementations, so if a
> file system implementation generates ENOENT in its readdir
> implementation, we might still see ENOENT in userspace.  That's why it's
> difficult to remove the check from glibc's readdir implementation.
>
> Thanks,
> Florian
>

Re: readdir and ENOENT error or EOF?

[Florian Weimer]

* Mark Olesen:

> Should ENOENT be handled as an error or is it indeed an EOF condition?

I don't know.  It's really hard to make such changes because there are
so many Linux file system implementations.  So we kind of default to
make not making changes. 8-/

Thanks,
Florian

Re: readdir and ENOENT error or EOF?

[Andreas Schwab]

On Jun 22 2021, Florian Weimer via Libc-alpha wrote:

> * Mark Olesen:
>
>> Should ENOENT be handled as an error or is it indeed an EOF condition?
>
> I don't know.  It's really hard to make such changes because there are
> so many Linux file system implementations.  So we kind of default to
> make not making changes. 8-/

POSIX makes it clear that when an EOF condition occurs, errno must be
left unchanged.  AFAICS, our readdir implementation conforms to that.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510  2552 DF73 E780 A9DA AEC1
"And now for something completely different."