[OpenAFS-win32-devel] problem with file open for read-only

[Jeffrey Altman]

Rodney M Dyer wrote:
> As far as I'm concerned, this is a "good" thing, because it prevents
> people from corrupting documents.  However it does seem disconcerting
> that the servers don't understand "whole lock read" vs. "whole lock
> write".  As the original poster seems to suggest, any files opened by
> one client will be "held hostage" until they are "released".  The
> original client should have been able to obtain a "whole file read/write
> lock", while all the other clients are just allowed to read the file
> (read-only).
> 
> Maybe I don't understand the problem, but don't office apps fall back to
> "read-only" when another client owns a "whole file write lock"?  Also,
> on Windows CIFS servers there are methods to release (bad) clients in
> case the locks get "hung".  We have no such methods under AFS right?  So
> we just have to wait until the lock times out?

A write-lock is exclusive.  When someone holds a write-lock no one else
can hold any other lock on the file.

A read-lock is shared.  When someone holds a read-lock any number of
other people can also obtain a read-lock.

If one or more read-locks are held, a write-lock cannot be obtained.

CIFS clients use optimistic byte-range locks (oplocks) which are used to
control the caching by the CIFS client.  A CIFS client can only cache
data on which it holds a lock.  The CIFS server uses callbacks to
invalidate regions of the lock when they are required for use by other
clients.

A client with an exclusive lock can refuse to give up the lock because
it in fact really needs it.  If the CIFS server says really you can't
have the lock, the file handle will be invalidated.

Jeffrey Altman