This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH] Fix readdir_r with long file names
- From: Siddhesh Poyarekar <siddhesh at redhat dot com>
- To: Florian Weimer <fweimer at redhat dot com>
- Cc: libc-alpha <libc-alpha at sourceware dot org>
- Date: Thu, 16 May 2013 18:20:29 +0530
- Subject: Re: [PATCH] Fix readdir_r with long file names
- References: <519220C7 dot 6050705 at redhat dot com> <20130516110136 dot GB11420 at spoyarek dot pnq dot redhat dot com> <5194CDEE dot 4020708 at redhat dot com>
On Thu, May 16, 2013 at 02:15:42PM +0200, Florian Weimer wrote:
> >Also, I don't think returning an error at the end of the traversal is
> >very useful. If we're adding an extension, we might as well go the
> >whole way and define something more useful: if the errno returned is
> >ENAMETOOLONG, then the directory can still be traversed and subsequent
> >readdir calls are still valid. At least one knows the position at
> >which the error occurred. This obviously makes the add-on
> >documentation even more important to highlight the difference.
>
> I think you really have to stop on the first error, otherwise you can
> end up with an endless loop (e.g., if the kernel reports a very
> low-level error such as EIO/ENXIO).
I did not suggest modifying the general error handling mechanism.
It's only in the case of the name buffer overflow that we ought to set
offsets to skip the entry and move ahead. That won't result in an
infinite loop. The recommendation in the manual for this would be
that if you encounter $THE_ERRNO_WE_FINALLY_AGREE_ON, it is safe to
proceed to the next entry since that errno only means that the current
entry name was too long; there was no system error that should
necessitate aborting the directory traversal.
Siddhesh