lkml.org 
[lkml]   [2008]   [Aug]   [12]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [RFC] readdir mess
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.


\
 
 \ /
  Last update: 2008-08-12 23:57    [W:0.073 / U:0.384 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site