>>>>> " " == Steve Dodd <steved@loth.demon.co.uk> writes:
> On Sun, May 07, 2000 at 11:35:01AM +0200, Trond Myklebust
> wrote:
>> >>>>> Linus Torvalds <torvalds@transmeta.com> writes:
> [..]
>> > - struct inode *inode = dentry->d_inode;
>> > + struct inode *inode = (struct inode*)page->mapping->host;
>>
>> No. Not good enough for those of us who actually need a
>> dentry. c.f. the 'readlink' code.
> Why isn't the inode good enough? What's the (doubtless
> embarassingly obvious) reason that I've missed for the file
> handle not simply being an (inode number, inode generation)
> pair?
See the RFCs 1094 and 1813. The NFS file handle concept is designed to
work with non-UNIX as well as UNIX file systems.
We consider the file handle to be the equivalent of a dentry rather
than an inode, since you are permitted by the RFCs to have several
inequvalent file handles that correspond to the same inode
number. Indeed knfsd file handles are designed like this to allow the
server to check that the user has the required permissions on the full
path (rather than just checking on the file). This is BTW going to
give us grief under NFS when we try to implement NFS3PROC_ACCESS for
inode->i_ops->permission().
Note that even internally in the Linux VFS, knowledge of the inode
number + inode generation provides insufficient information for
retrieving info on a file (see FAT, smbfs, and other non-inode
oriented filesystems...) something which can be a considerable
headache for the knfsd people.
Cheers,
Trond
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Sun May 07 2000 - 21:00:20 EST