Many applications on Windows (e.g. Microsoft Office) require the use of byte range locks applied to a file either to protect against simultaneous file access or as a signaling mechanism.   OpenAFS for Windows release 1.5 (or greater) implements byte range locking within the CIFS-AFS gateway server.   This support for byte range locking obtains AFS’ advisory file server locks to simulate Microsoft Windows mandatory locks.   When an application opens a file, a lock will be obtained from AFS indicating that the file is in use.  If the lock is a write lock, access to the file will be restricted to other applications running on the same machine as the first application to request the lock.   Applications running on other machines will see the AFS full file lock and will be unable to access the file.

Most Windows applications and Windows itself opens files in shared read mode. When this is done, a read lock is applied to the file.   This does not prevent shared read access across multiple machines but is used to ensure that no one writes to the file while it is in use.

As the CIFS-AFS gateway server attempts to implement Windows lock semantics on top of AFS lock semantics it is important to understand how AFS file locks work.  In Windows there are no special privileges associated with obtaining file locks.  If you can read or execute a file, then you can obtain shared and exclusive locks.  In general, a Windows shared lock equates to an AFS read lock and a Windows exclusive lock equates to an AFS write lock.  In AFS if you can write to a file, then you can obtain a write lock.  However, in AFS if you can read a file it does not mean that you can obtain a read lock on it.   The ability to obtain read locks is granted only if you have the lock (or ‘k’) privilege.  This behavior is required in order to allow anonymous users to read files while preventing them from being able to deny access to the files to other users.  OpenAFS 1.4.0 and earlier as well as all IBM AFS file servers have an implementation bug that prevents users with write privileges from being able to obtain locks without the lock privilege.  When AFS serves data out of read-only volumes the file server will deny all requests for read and write locks because the contents of the volume cannot be changed by the client.

Since Microsoft Windows applications almost always attempt to obtain a temporary exclusive lock when accessing files the OpenAFS Client’s CIFS-AFS gateway implements the following semantics in order to reduce the inconvenience on end users. 

If you wish to disable the acquisition of locks from the file server, this can be performed using the EnableServerLocks registry value.