[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20080812205943.GX28946@ZenIV.linux.org.uk>
Date: Tue, 12 Aug 2008 21:59:43 +0100
From: Al Viro <viro@...IV.linux.org.uk>
To: Linus Torvalds <torvalds@...ux-foundation.org>
Cc: OGAWA Hirofumi <hirofumi@...l.parknet.co.jp>,
linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [RFC] readdir mess
On Tue, Aug 12, 2008 at 01:05:43PM -0700, Linus Torvalds wrote:
>
>
> On Wed, 13 Aug 2008, OGAWA Hirofumi wrote:
> >
> > However, there are some similar stuff: ->st_size, ->st_nlink and
> > ->st_ino in stat() (cp_old_stat()). Maybe EOVERFLOW is the reason for
> > consistency...
>
> .. I actually had an old binary that triggered that case (actually, it was
> O_LARGEFILE in open()), and didn't work as a result. I only needed to run
> it once, so I literally hacked up a once-time-use kernel that just removed
> the EOVERFLOW in open.
>
> So no, I'm not a fan of EOVERFLOW at all. Not in readdir(), not really
> anywhere else.
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? open() on a huge file is a different story, since you
would get a valid opened file and that'd be it; the logics in case of
open() is, IIRC, "I guess your binary is old, so it'll probably do other
things that would really have to trigger -EOVERFLOW; better bail out right
now". In this case, though, you either generate an error or get wrong
values silently stored in userland struct (wrapped around inumber).
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists