NFS File identity resolution?

[Robert Thurlow]

In <20103:Mar1423:16:4291 at kramden.acf.nyu.edu> brnstnd at kramden.acf.nyu.edu (Dan Bernstein) writes:

>In article <21078 at shlump.nac.dec.com> prakash at aiag.enet.dec.com writes:
>> Given a set of NFS servers and clients on the same network, and two
>> processes A and B on possibly different nodes, which can communicate
>> using sockets. How can the two processes determine if a file referred to
>> as "/a/b/c/file" by process A is really the file referred to as "/A/B/file"
>> by the process B?

>You cannot, at least not reliably.

>On a single machine, two files are the same if and only if they have the
>same device and inode (st_dev and st_ino after stat()). But there are
>simply no guarantees of this across multiple machines.

You can, and reliably, but it's a bitch.  You have the inode number
on the remote machine, and if you tapdance and walk through /etc/fstab
and make sure you resolve all of the symlinks out of all your paths,
you can get an identifier of the remote machine is question.  Is it
really worth the pain?

>Even if you could find out that the two files were the same, what would
>you want to do with the information? NFS doesn't even guarantee that
>locks on the file will work right.

NFS doesn't do locks, Dan; haven't you been paying attention?  The
lock protocol does work for remote files; what is suspect is your
lock manager implementation.

>Even if you could find out that two pathnames referred to the same file,
>and even if you could do something sensible with the file, you wouldn't
>want to use the names. What if someone moved the file or unmounted and
>remounted the disks in the meantime?

Well, boundary conditions like this exist on strictly local systems,
as well, Dan; it doesn't seem to stop people from using them.  I agree
that this is not a thing to do capriciously for the reasons you give.

Rob T
--
Rob Thurlow, thurlow at convex.com
An employee and not a spokesman for Convex Computer Corp., Dallas, TX