Jeffrey Altman wrote: > If the files are truly intended for read-only use, store them in a > directory that provides only 'rl' access to the end users or store them > in a .readonly volume. In both of those cases the AFS Cache Manager > knows that the user cannot obtain a lock on the file and will issue one > locally. > > Jeffrey Altman
Now that I am back in my own timezone let me take the time to explain a bit more about locking and Microsoft Office applications. Office applications will obtain an exclusive lock on a file even when the file is being opened in "read only" mode. OAFW will translate "file open for read and not write and not delete" and "request for exclusive lock" as meaning "obtain a read lock on the file". The problem that you are experiencing is that while the Office application is requesting a lock for a very small subset of the file, AFS only implements full file locks. If Office applications are two machines attempt to open the same file and the first one has the file open for write, the second one won't be able to open for read because lock requests that otherwise would be non-intersecting byte ranges collide when translated into full file locks. Therefore, if you are providing files to be used simply as read only templates, they should be stored in AFS in a manner that indicates to the AFS client that they are in fact readonly so that the cache manager knows it is safe to fake the locks locally. Jeffrey Altman
smime.p7s
Description: S/MIME Cryptographic Signature
