Re: IMPORTANT: Byte Range Locking Installers available

New builds have been uploaded that correct two significant errors:

 * locks were being marked lost prematurely when network communication
   with the file server was unstable

 * lock counts were not being managed properly when file were closed
   when the locks were lost.

With these two fixes I believe that the Byte Range Lock support is
stable.   Please try these builds and report your experiences.

Thanks for Asanka Herath for his efforts designing and implementing
these changes.

Jeffrey Altman

Jeffrey Altman wrote:

> Starting today a new set of installers built off of the 1_4_x branch
> including support for the Byte Range Locking code are now available for
> testing.   These installers are the first release on the road to 1.4.1.
> They can be found at:
> 
>   http://web.mit.edu/user/j/a/jaltman/Public/OpenAFS/ByteRangeLocks/
>   \\afs\athena.mit.edu\user\j\a\jaltman\Public/OpenAFS\ByteRangeLocks\
>   /afs/athena.mit.edu/user/j/a/jaltman/Public/OpenAFS/ByteRangeLocks/
> 
> As a user of these builds you are going to notice some fairly
> significant changes in behavior.   Windows relies on a mandatory locking
> model whereas AFS relies on an advisory locking model.   Windows
> applications in most cases attempt to obtain a lock or check to see if
> there is a lock when opening files.   Windows itself always checks for
> locks when attempting to execute files.   One of the side effects is
> that if a user attempts to execute/open a file in a non-readonly volume
> from a directory in which they do not have locking 'k' privileges, the
> attempt to open the file is going to fail with an "access denied" error.
> 
> Organizations that wish to allow "system:anyuser" or "system:authuser"
> to execute applications must add the 'k' privilege to all directories
> containing publicly available files.  A failure to do so will result in
> significant numbers of support calls as end users are inconvenienced by
> "access denied" errors.
> 
> This change is going to be a major backward compatibility issue and I
> am not entirely sure how we are going to get the word out prior to the
> release of 1.4.1.
> 
> Jeffrey Altman
> 
> 
> 
> 
>