I don't think Christoph will like the patch better, regardless of how

I change the description.
Of course, I'm open to suggestion on how to improve the interface, but

I think fundamentally this is the only way to correctly deal with the

below problem.
Anyway, here's the patch another time, please consider adding it to

-mm.  For 2.6.25 obviously.
Thanks,

Miklos

----
From: Miklos Szeredi <mszeredi@suse.cz>
Add a new file operation: f_op->fgetattr(), that is invoked by

fstat().  Fall back to i_op->getattr() if it is not defined.
We need this because fstat() semantics can in some cases be better

implemented if the filesystem has the open file available.
Let's take the following example: we have a network filesystem, with

the server implemented as an unprivileged userspace process running on

a UNIX system (this is basically what sshfs does).
We want the filesystem to follow the familiar UNIX file semantics as

closely as possible.  If for example we have this sequence of events,

we still would like fstat to work correctly:
 1) file X is opened on client

 2) file X is renamed to Y on server

 3) fstat() is performed on open file descriptor on client
This is only possible if the filesystem server acutally uses fstat()

on a file descriptor obtained when the file was opened.  Which means,

the filesystem client needs a way to get this information from the

VFS.
Even if we assume, that the remote filesystem never changes, it is

difficult to implement open-unlink-fstat semantics correctly in the

client, without having this information.
Signed-off-by: Miklos Szeredi <mszeredi@suse.cz>

---
Index: linux/fs/stat.c

===================================================================

--- linux.orig/fs/stat.c	2007-10-24 11:59:46.000000000 +0200

+++ linux/fs/stat.c	2007-10-24 11:59:47.000000000 +0200

@@ -55,6 +55,33 @@ int vfs_getattr(struct vfsmount *mnt, st
 EXPORT_SYMBOL(vfs_getattr);
+/*

+ * Perform getattr on an open file

+ *

+ * Fall back t...
[ message continues ]

This true iff the protocol that this mythical network file

system uses the name of the file on the server to actually

identify the file on the server.
Clearly, this is broken on many levels.  It can't handle

situations as described nor can it handle different instances

of the same filename being used.
This is why NFS, a network file system, does not use the filename

as part of the file handle.
Wouldn't you be better off by attempting to implement an "open

by ino" operation and an operation to get the generation count

for the file and then modifying the network protocol of interest

to use these as identifiers for the file to be manipulated?
I agree with Christoph on this one.  It is the wrong path.
-

Not mythical at all.  As noted in the description, there's sshfs, a
The constraint is that the server has to be an ordinary unprivileged

process.  How should it identify the file, other than by name, or by
Can you please give concrete examples what it can't handle, and how

should the implementation be improved to be able to handle it, given
And the nfs server isn't a userspace process, or if it is, it must use

horrible hacks to convert the file handle to a name, that don't work
You mean an "open by inode" on the userspace API?  My guess, it

wouldn't get very far.
Anyway, that would still not work on old servers, and servers running

other OS's.
Note, the point is _not_ to make a brand new NFS replacement

filesystem, that can use names instead of file handles.  The point is

to use existing infrastructure, to make the setup as easy as ssh'ing

to a different machine.  And sshfs does just that.
Miklos

-

I explained this.  The fileid and the generation count along
This isn't a new idea and has been implemented on a variety of
I didn't think that we were talking about old servers and other

OS's.  My concern at the moment is Linux and the changes being
And the solution is limiting.  It is not scalable nor particularly

interesting to anyone interested in security.  Unless there is a

way of limiting access to a particular set of files, then it is

not generally useful outside of hackers or perhaps small groups

of users not concerned about too many aspects of security.
I am not interested in an extended discussion of this topic.
    Thanx...
       ps

-

Yes, those filesystems, which have a file ID that can be used to index

the inodes.  Lot of filesystems (mostly those not originating from
In what way does passing the open file to the filesystem for the

fstat() syscall negatively impact Linux?
Usually it is best to design midlayers, so that they do the minimal

stuff, and pass the maximum of information to the low-layer, and

providing helper functions that the low-layer doesn't want to do
I'm not sure what you are talking about here.  AFAICS this change

has absolutely nothing to do with filesystem (or any other kind of)
No problem.  Thanks anyway for your comments.
Miklos

-

XFS.
'man open_by_handle'
Cheers,
Dave.

--

Dave Chinner

Principal Engineer

SGI Australian Software Group

-

Doesn't seem widely used, with 600 something google hits.  And in this

old thread Linus is not entirely enthusiastic about the concept:
  http://lkml.org/lkml/1999/1/11/244
Miklos

-

from the man page:
"They are intended  for  use  by a limited set of system utilities such

as backup programs."
It also gets used by HSMs and so it is current, tested and is not
That was "open by inode number", AFAICT. A handle is an opaque

blob that can be an arbitrary length defined by the filesystem.

You have to convert a fd or path to a handle first before you can

use it later, so any filesystem can implement it...
i.e. it is exactly what this (unanswered) post suggested:
http://lkml.org/lkml/1999/1/13/186
Just my 2c worth....
Cheers,
Dave.

--

Dave Chinner

Principal Engineer

SGI Australian Software Group

-

Well, yeah, if a filesystem doesn't have a global index, the whole

path could just be stuffed into the handle.
But there's not much point in that, is there?  And because the

interface bypasses normal access checking on parent directories, it

has security implications, making it not generally useful.
Specifically, it is not useful for the "unprivileged file server" case

that Peter was suggesting.
Miklos

-