> On Mon, Sep 24, 2007 at 03:18:10PM +0200, Miklos Szeredi wrote:
quoted text
> > > Or not support such a broken protocol at all.
> > 
> > Wonder what people would say if we removed support for NFSv[23].
> > 
> > Just because a protocol does not support "perfect" UNIX semantics, it
> > doesn't mean it's broken.  By that standard almost all network
> > filesystem protocols are severely broken.
> 
> Well, they are broken by these and other standards.  At least nfs and
> cifs maintainers do the workarounds for this brokeness where they belong.

And my patch is not working around a problem, rather solving a problem
in a correct way.

Let me summarise it:

There are valid reasons we have fstat() in addition to stat/lstat.
For example we want to protect agains races involving unlink/rename on
an open file.

Say I want to implement a network filesystem with a pure unprivileged
userspace sever (this is basically what sshfs does).

I want my filesystem client implementation to keep all these
advantages of fstat().  So how can I do that?  There's a simple way:
implement this operation with fstat() on the server.  I get all the
advantages on the remote system automatically.

But for that the filesystem needs to have the open file that the
fstat() on the client was performed on.

It's that simple.  There's really no ugly hacks going on behind the
scenes.  It's just that we do want to delegate some properties of this
operation onto the server, and the simplest and best implementation is
to just let the filesystem have the information it needs.

Why is that such a big problem?

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/