>> 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?

					der Mouse

			    mouse@collatz.mcrcim.mcgill.edu