Re: [RFC] readdir mess

[Al Viro <viro@ZenIV.linux.org.uk>]

On Tue, Aug 12, 2008 at 02:24:04PM -0700, Linus Torvalds wrote:

> On Tue, 12 Aug 2008, Al Viro wrote:
> > 
> > Um...  Here it would happen only on attempt to return an entry for file
> > that really has an inumber not fitting into the field; what would you
> > do in such case?
> 
> You'd truncate the inode number. What's the big deal? Inode numbers aren't 
> that important - they're just about the _least_ important part of the data 
> returned for a readdir. 

Tell that to tar(1) ;-)
 
> But I also think that we're not in a transition period any more, and as a 
> result the annoyance part is just annoying an doesn't help find and fix 
> problems any more, it just makes legacy binaries not work even if they 
> could otherwise work fine (and _maybe_ have problems).
> 
> So something that made sense five years ago may not make sense any more, 
> is what I'm saying. These days, if somebody runs legacy binaries, they do 
> it because of archeology reasons or similar..

I suspect that SUS specifies that crap in some cases, but I honestly do not
remember.  For large offsets, that is.  Large inode numbers are more recent
and hit relatively few filesystems.  OTOH, I suspect that most of getdents()
call sites are in libc anyway...

Anyway, the point for getdents() is simply that we *do* return an error; it's
just that it ends up with -EINVAL instead of -EOVERFLOW, and that's simply
bogus - we should either truncate silently or return the right value.  The
code definitely intends to do the latter and fucks up.