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>, mtk dot manpages at gmail dot com
- Date: Thu, 16 May 2013 18:39:52 +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> <20130516125029 dot GE11420 at spoyarek dot pnq dot redhat dot com> <5194D697 dot 8040106 at redhat dot com>
On Thu, May 16, 2013 at 02:52:39PM +0200, Florian Weimer wrote:
> On 05/16/2013 02:50 PM, Siddhesh Poyarekar wrote:
> >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.
>
> This will break existing applications which currently treat the
> garbled d_name as a concurrently deleted directory entry and move on.
> If we change the behavior as you suggest, the directory list will be
> truncated at the first long name until the application is updated.
Hrm, right. I still don't like the idea of putting the errno at the
end, but I guess that is the best available option.
The reposted patch looks fine to me, but I'd like a native English
speaker to review the manual bits. I've added Michael Kerrisk to cc
in case he wants to update the man page for this. Of course, the
errno still needs to be agreed upon - I like the original NAMETOOLONG
since it conveys perfectly what the failure really is, but I don't
mind if it's something else that makes enough sense.
Siddhesh