Subject: Re: link() apparently nonatomic
To: None <netbsd-bugs@NetBSD.ORG>
From: der Mouse <mouse@Collatz.McRCIM.McGill.EDU>
Date: 04/19/1996 14:16:50
>> We are using a link() based locking routine for use over NFS on our
>> web servers running NetBSD. This routine has been failing with
>> multiple processes gaining the lock simultaniously.
> This is normal and happens AFAIK on all UNIX versions.
Only when the server or client is broken. Unless the client is broken,
link() simply turns into a LINK request, request number 12. Unless the
server is broken, this is atomic with respect to LINK request from
other clients and link() calls on the server. (The only excuse I can
see at all for allowing failed locks to appear to succeed is handling
of the non-idempotency aspect of the LINK request, which could provoke
client code authors to treat EEXIST returns as success. If this is
done without verifying that the linked-to name actually refers to the
file the request attempted to link to, the client code is broken - and
it should _never_ be done unless the client retransmitted the request.)
> Anyway, the mail user agent guys have discussed this to death years
> ago and haven't been able to find a way to relibably do file based
> locking over NFS.
That's hard to understand; the necessary theory has been known for
years. Are there client implementations that cache too much, that
can't be made to go to the server when the theory requires it?