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

quoted text
> 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) ;-)
 
quoted text
> 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.
--
unsubscribe notice
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/