Path: utzoo!news-server.csri.toronto.edu!rpi!usc!cs.utexas.edu!yale!cmcl2!kramden.acf.nyu.edu!brnstnd From: brnstnd@kramden.acf.nyu.edu (Dan Bernstein) Newsgroups: comp.unix.shell Subject: Re: NFS File identity resolution? Message-ID: <6986:Mar1812:34:0091@kramden.acf.nyu.edu> Date: 18 Mar 91 12:34:00 GMT References: <21078@shlump.nac.dec.com> <20103:Mar1423:16:4291@kramden.acf.nyu.edu> Organization: IR Lines: 24 In article thurlow@convex.com (Robert Thurlow) writes: > In <20103:Mar1423:16:4291@kramden.acf.nyu.edu> brnstnd@kramden.acf.nyu.edu (Dan Bernstein) writes: > >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? I was referring to NFS, the (exceedingly buggy and unreliable) network filesystem, all recent implementations of which include a lock manager over and above the basic NFS client and server. > >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. Those reasons imply that the operation in question is not reliable. There is no way to reliably access two regular file names at once. Period. ---Dan