[OpenAFS-announce] OpenAFS 1.4.1 Release Candidate 2 now available

[Derrick J Brashear]

The OpenAFS Gatekeepers announce the availability of OpenAFS version
1.4.1 Release Candidate 2.  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/

Major changes new to 1.4.1 from 1.4.0:

  - Support for MacOS X 10.4 (Tiger)

    Thanks to Chaskiel Grundman for the port.

  - 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:

  - A bug in callback handling for readonly volumes in the Unix clients has
    been fixed.
  - MacOS 10.3 support has been updated.
  - Several MacOS 10.4 issues have been addressed.
  - A memory leak in Rx has been corrected.
  - A lock leak in Rx has been corrected.
  - A bug in the Windows client which could cause a missing vnode error to
    be misinterpreted has been corrected.
  - Server preferences will now be correctly retained in all cases in the
    Windows client.
  - Windows clients now check "up" servers for continued connectivity every
    10 minutes instead of hourly, to match Unix client behavior.

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 openafs-bugs@openafs.org.
Reports of success should be sent to openafs-info@openafs.org.

Derrick J Brashear
for the OpenAFS Gatekeepers