> > 2. As afsd works asynchronously, if I release the lock on file B
> > after closing file A there is probably no guarantee for the file
> > server and for other AFS clients to see that information in the
> > same order.
> I believe that AFS file locks are supposed to be synchronous: when
> the last locker unlocks a file, the servers should be told. Of
> course, you might have wanted to do an fsync() on the file before
> unlocking it, so that when other clients see the unlocked file, they
> also see the updated data, mtime, and EOF.
I hope this is true for a single AFS file. However, the suggestion was
to lock a different file than the one that is written to.
> The only thing I remember about AFS locks is that if an flock() call
> fails with EWOULDBLOCK or the like, you have to close the file and
> open it again before you can meaningfully retry the flock() request.
This is one of the solutions I considered. However, since flock still
happens after open, not atomically together with open, there is still
no guarantee that no other AFS client hits into the time frame between
the two operations. Chances for file corruption would be reduced,
though.
--
Michael Niksch TEL: +41-1-7248-913
IBM Zurich Research Laboratory FAX: +41-1-7103608
Saeumerstrasse 4 SMTP: [EMAIL PROTECTED]
CH-8803 Rueschlikon / Switzerland RSCS: NIK at ZURICH
