[OpenAFS] MS Word crashing when opening files, 1.5.27 client

Fri, 30 Nov 2007 02:18:05 +0100

This is a multi-part message in MIME format.
--------------070805080608030703090400
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Thanks Jeffrey,

<snip>

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.

Would this also be achieved when we vos release this volume to a ro 
clone ? (not necessarily on another fileserver?)

I wonder what common practice is for this kind of shared volumes;  This 
one is a "projects" folder where everybody stores his or her additions 
to several projects, so, alot of files are opened as templates to make 
new ones that are also stored in the same folder or subfolders.
If a readonly copy could solve this locking problems (or at least will 
bring the number of occurences down) we'll have to do alot of vos 
release commands throughout the day to avoid the locking problems as 
much as possible. How do you handle this ?

Hans

Jeffrey Altman wrote:
> 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
>   

--------------070805080608030703090400
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
  <title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
Thanks Jeffrey,<br>
<br>
&lt;snip&gt;<br>
<pre wrap="">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.</pre>
Would this also be achieved when we vos release this volume to a ro
clone ? (not necessarily on another fileserver?)<br>
<br>
I wonder what common practice is for this kind of shared volumes;&nbsp; This
one is a "projects" folder where everybody stores his or her additions
to several projects, so, alot of files are opened as templates to make
new ones that are also stored in the same folder or subfolders.<br>
If a readonly copy could solve this locking problems (or at least will
bring the number of occurences down) we'll have to do alot of vos
release commands throughout the day to avoid the locking problems as
much as possible. How do you handle this ?<br>
<br>
Hans<br>
<br>
<br>
<br>
Jeffrey Altman wrote:
<blockquote cite="mid:474EE1D2.4010407@secure-endpoints.com" type="cite">
  <pre wrap="">Jeffrey Altman wrote:
  </pre>
  <blockquote type="cite">
    <pre wrap="">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
    </pre>
  </blockquote>
  <pre wrap=""><!---->
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
  </pre>
</blockquote>
</body>
</html>

--------------070805080608030703090400--