thurlow@convex.com (Robert Thurlow) (01/23/91)
In <2909@cirrusl.UUCP> dhesi%cirrusl@oliveb.ATC.olivetti.com (Rahul Dhesi) writes: >Sun's locking daemons have never worked correctly whenever I have tried >them. Sounds a bit harsh to me. I have a few problems with the robustness of the daemon, but it does seem to work. I have high hopes for the NFSSRC 4.1 version, mainly because I haven't seen the source code yet :-) >I finally decided that it would be better to rely on the >standard reliable UNIX method: create a lock file. I used this >successfully for a while. Then discovered with a shock that NFS has no >mechanism for ensuring exclusive creation of a file even if the O_EXCL >flag is given to open(). Correct. open() maps in an odd way to the over-the-wire ops, and if you do get the idea that you can create a node, the create op doesn't have an exclusive flag over-the-wire. This is one of the top three protocol bugs in the product. I'm personally more frustrated by the lack of an over-the-wire access() op, myself. >NFS does make symbolic links links correctly. [code to do locking with symlinks and hard links.] Guess what? It won't be reliable all the time, either. If you have a server which doesn't detect duplicate requests properly (and I think anything based on NFS 3.2 did this), when the server gets slow, it will get a pair of these requests due to timeouts and will return an error on the second attempt. *Most* won't do this, but I don't really get the feeling that that *most* is more bankable in general than "lockf() works *most* of the time." [I've redirected followups to comp.protocols.nfs as we've drifted a bit.] Rob T -- Rob Thurlow, thurlow@convex.com or thurlow%convex.com@uxc.cso.uiuc.edu "The Canadian rock singer, Ronnie Hawkins, has it all figured out. 'Believe in God?' he says, "Man, I believe in God like nobody else. It's the fucking ground crew I don't trust." - "Running Risks", Angela Issajenko