Path: utzoo!news-server.csri.toronto.edu!cs.utexas.edu!sun-barr!olivea!uunet!munnari.oz.au!metro!cluster!necisa!boyd
From: boyd@necisa.ho.necisa.oz.au (Boyd Roberts)
Newsgroups: comp.unix.shell
Subject: Re: NFS File identity resolution?
Message-ID: <2046@necisa.ho.necisa.oz.au>
Date: 18 Mar 91 01:16:14 GMT
References: <21078@shlump.nac.dec.com> <1991Mar14.150249.21054@mp.cs.niu.edu>
Followup-To: comp.unix.misc
Organization: NEC Information Systems Australia Pty. Ltd.
Lines: 28

In article <21078@shlump.nac.dec.com> prakash@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? In other words, on the node of the process A, "/a/c/b"
>

Comparing the file-handles will do the job.  But you have to be sure
that the two files are on the same host.  A byte by byte comparison
will do the trick.  There's an NFS call to take a file-descriptor and
return a file-handle (nfs_getfh(2)).

All those other replies about inode numbers are just bogus.  You need
the inode number, dev and generation number.  All that stuff is bundled
into the file handle.  You don't have to worry about the contents of the
file-handle (the object is an opaque cookie anyway), just that the bits
are the same.

And what the hell is this discussion doing in comp.unix.shell?
comp.unix.misc would be a better choice.  Followups to there.


Boyd Roberts			boyd@necisa.ho.necisa.oz.au

``When the going gets wierd, the weird turn pro...''