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/