Messages in this thread | | | From | Michael Kaminsky <> | Subject | Re: NFSv3 support (bugs, some fixes, and more) | Date | Mon, 12 Jul 1999 13:47:00 -0400 |
| |
On 12 Jul 1999 14:19:20 +0200, Trond Myklebust writes: > This will not work. You can't use the filehandle, since it is not > unique to the inode (consider hard links).
RFC 1813 (NFSv3) says
To the client, the file handle is opaque. The client stores file handles for use in a later request and can compare two file handles from the same server for equality by doing a byte-by-byte comparison, but cannot otherwise interpret the contents of file handles. If two file handles from the same server are equal, they must refer to the same file, but if they are not equal, no conclusions can be drawn. Servers should try to maintain a one-to-one correspondence between file handles and files, but this is not required. Clients should use file handle comparisons only to improve performance, not for correct behavior.
From my reading of the above, if an NFS server returns a different file handle for two files that are hard-linked (i.e., the same file on the server), the client cannot assume that they are the same ("no conclusions can be drawn"). So, in the hard link case, the server should be returning the same handle (and the same fileid), right?
As a somewhat related issue: what if an NFS server does export two different files with different handles but the same fileid? (Say I export / twice, the second time on a subdirectory of itself. It's a weird thing to do, but legal.) To the Linux kernel, they'll look like the same file (with the same struct inode) because they have the same fileid. But again looking at the RFC, the client shouldn't (can't) assume they are the same file.
Ultimately, however, it's probably a pragmatic/security issue if a rogue NFS server can confuse the Linux kernel into a less-than-stable state by reusing fileids with different handles.
Michael
- 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/
| |