Christian Schwarz wrote: >AFAIK, there is at least one safe way to lock a file over NFS. The >procedure is partially explained in the open(2) man page and is also >implemented, for example, in your "publib" library.
I've dug deeper into the NFS protocol (RFC 1057 and RFC 1094) than is good for me :-) and I don't think there is such a thing for NFS over UDP without a lockd, which Linux doesn't have. The problem is that any NFS request (CREATE, LINK, ...) can get lost, and its ack can get lost, too. Let's take a CREATE request. If no ack comes back, there are several cases the client can't tell apart: a) Server never got the request. b) Server got the request, but the lockfile already existed (status = NFSERR_EXIST), and the reply got lost c) Server got the request, and created the lockfile (status = NFS_OK), but the reply got lost. If the client retries and gets status=NFSERR_EXIST after not hearing anything from the server, what should it assume that b) or c) happened previously? Yes, the server can do xid caching to a certain extent, but the client can't rely on that. If the protocol in the publib library has a way to get around that problem, I'd be interesting in learning more about it (and, possibly, dreaming up cases in which it might fail :-) -- Thomas Koenig, [EMAIL PROTECTED], [EMAIL PROTECTED] The joy of engineering is to find a straight line on a double logarithmic diagram. -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .