Lars Wirzenius wrote: [replying to the list instead of privately, since this is of common interest, IMHO :-]
>> 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 :-) > >I don't know if it does, but it tries. Please do find any problems. >Here's the code: [...] > fndir(dir, lockname); > fnjoin(tempname, dir, ".temp-lock"); > fd = open(tempname, O_CREAT | O_EXCL, 0600); > if (fd == -1) > return -1; This can create a lockfile that is never deleted. Consider the following case: Client code does open(tempname, O_CREAT | O_EXCL, 0600); Client kernel translates this into a NFSPROC_CREATE RPC call and sends it out on the wire as a UDP packet. Server receives the RPC call and executes it via doing an open(tempname, O_CREAT | O_EXCL, 0600) itself; the lockfile is created. Server sends back the the acknowledgement of success via a UDP package. UDP package is lost on the wire. Client kernel receives no confirmation and re-transmits the NFSPROC_CREATE request. Server receives RPC call and does open(tempname, O_CREAT | O_EXCL, 0600); This call fails; server transmits back indication of failure. Client user-space code sees call to open(tempname, O_CREAT | O_EXCL, 0600) fail and thinks that somebody else has already locked things. Result: oops... There is a - partial - way around this. Each RPC call is accompanied with a unique 32-bit number, the xid. A server can cache the first request and simply send back a "done successfully" if it sees the same (hostname,xid) tuple again within a certain time. However, there is no guarantee in the NFS protocol that this is indeed being done (and I don't know wether the current Linux nfsd does indeed follow that strategy). This will also not survive a server crash, and there is no way to enquire wether the server does support xid caching. -- 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] .
