OpenAFS 1.4.1 Release Candidate 1 now available

The OpenAFS Gatekeepers announce the availability of OpenAFS version
1.4.1 Release Candidate 1.  Source files and available binaries can be
accessed via the web at:

    http://www.openafs.org/dl/openafs/candidate/1.4.1-rc1/

or via AFS at:

    /afs/grand.central.org/software/openafs/candidate/1.4.1-rc1/

The 1.4.1 release candidates are being issued prior to the announcement
of 1.4.0 (final) in order to accelerate the testing process for two
major enhancements that were not ready in time for 1.4.0.

 - Support for MacOS X 10.4 (Tiger)

   Thanks to Chas Grundman and Derrick Brashear for all of their
   hard work.

 - Support for Client Managed Byte Range Locks on Microsoft Windows

   Thanks to Asanka Herath for the implementation and Swiss Federal
   Institute of Technology for their support.

Other changes since 1.4.0:

 - A change to the audit logging of the viced Create File operation
   to include the file identifier assigned to the created file.


Important notes on Byte Range Locking support:

The byte range locking uses AFS' full file locks to simulate byte range
locks.   When Windows applications open a file in shared mode, a read or
write lock (as appropriate) is registered indicating that the file is in
use.  If the lock is a write lock, the use of the file will be
restricted to other applications running on the same machine as the
first application to apply the lock.   Applications running on other
machines will see the lock and will be unable to access the file.

The vast majority of Windows applications and Windows itself opens files
in shared read mode.  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 locks are requested during the file open
operation, it is crucial that users have the lock, 'k', privilege in all
directories in which the user might read a file or execute an
application unless the directory exists on a read only volume.  A
failure to assign the 'k' privilege will result in "Access Denied"
errors during the file open operation.

After a full lock is obtained, the Windows cache manager maintains a
list of the byte ranges locked by each session.  Locks registered in AFS
expire in five minutes unless they are renewed.   If a lock is lost due
to network failure or perhaps suspension of a laptop, the file will be
considered inaccessible.  Future attempts to read or write the file will
result in an Invalid Handle error.  Users will have to save their data
to an alternate file name and manually determine whether or not it is
safe to replace the original.  This is behavior is required because once
a lock is lost it is not safe to assume the file was not altered in the
meantime.

The additional of byte range locking is going to require a significant
educational effort of users and support staff.  Previous releases of
OpenAFS for Windows did not enforce locking and this resulted in a risk
of data corruption.  By enforcing locking, we remove the risk of data
corruption at the cost of inconveniencing the end users and requiring
additional privileges on directories used for Windows applications.


Please Test and Submit Bug Reports:

Please assist us by testing this release candidate and providing
feedback. Bug reports should be filed to [email protected].
Reports of success should be sent to [email protected].

Jeffrey Altman
on behalf of the OpenAFS Gatekeepers