> On Fri, Sep 21, 2007 at 10:32:31AM -0400, Trond Myklebust wrote:
quoted text
> > On Fri, 2007-09-21 at 15:16 +0200, Miklos Szeredi wrote:
> > 
> > > > ftruncate is a special case due to O_TRUNC.
> > > 
> > > No, it's special, because it does not do permission checking, while
> > > truncate() does.
> > 
> > So why not just add file->f_op->ftruncate() and file->f_op->fstat()?
> > Most filesystems can trivially redirect these to do_truncate() and their
> > existing getattr() method. Those, like FUSE, that care can use the hook.
> > In fact, I think that NFSv4 could also benefit from an ftruncate():
> > currently we have to hunt around for an open file context for that
> > particular case.
> 
> Havin the file for fruncate is fine and I'm planning to do something
> along those lines.  Having it for (f)stat is dumb because the operation
> is in no way related to the open file descriptor.

What I'm saying is that read and write are _no_more_ related to the
file than fstat.  Read/write operate on inode data, fstat operates on
inode metadata.

OK, read/write have a position state in the open file, but that is
something the filesystem should _never_ touch anyway, so it's
irrelevant to the discussion.

The fact is, if the filesystem uses a stateful open API, which defines
an fstat() operation, it can be useful to use that instead of the
plain stat().  But that is only possible if the VFS supplies the open
file, otherwise there will be just "hunting around" for suitable open
files, or "sillyrenaming".  None of which is desirable.

Miklos
-
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/