Excerpts from transarc.external.info-afs: 18-Jan-95 Re: File locking in
AFS "Michael Niksch"@zurich. (822*)
> 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.
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.
Excerpts from transarc.external.info-afs: 18-Jan-95 Re: File locking in
AFS "What's in a name?"@iast (969*)
> Don't know if I am missed the mark here but I think you have to close
> the file after you unlock to make sure the cache manager keep thing
> consistent. Also check the errors return from the close to make sure
> that it is indeed closed.
I think that this is addressed a bit better by doing fsync() *before*
doing the unlock, rather than by doing a close() *after* the unlock.
Also, if there are going to be errors in storing back the file, you can
check for them by checking the return code from fsync(), before the file
is unlocked.
Craig
