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

[Derrick J Brashear]

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

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

or via AFS at:

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

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:

  - Windows clients now properly clean up SMB Virtual Circuits upon
    SMB session disconnect
  - A fix to the Windows procmgmt library prevents tools that
    dynamically unload the library from crashing at process
    termination.
  - Many MacOS 10.4 issues have been addressed, several since the last
    candidate (again).
  - A memory leak when removing files has been corrected.
  - A potential deadlock when removing files has been fixed.
  - A bug in callback handling for readonly volumes in the Unix clients has
    been fixed.
  - MacOS 10.3 support has been updated.
  - 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 for Microsoft Windows:

The byte range locking support in 1.4.1 does *not* enforce the allocated
locks across multiple machines by obtaining file locks from the AFS
file servers.  The use of AFS file locks will be added in a future
release.  In 1.4.1, the OpenAFS Client Service will respond to lock
requests by locally managing the allocated locks on a per-machine basis.
This will prevent two processes on the same machine from stepping on
each other's toes.  However, it will not prevent two processes on
separate machines from doing so.

The vast majority of Microsoft Windows applications use file locks
to protect their data or to signal other applications that are sharing
the same files.  Microsoft Windows itself uses file locks to restrict
access to files that are being opened by the "loader" prior to
execution.  In a future release of OpenAFS, locks allocated by the
Client Service will be backed by AFS file locks.   When this change
occurs it will be necessary for users to have the 'k' privilege in
order to be allowed to execute files from read-write volumes and open
data files within applications that request file locks, including the
Microsoft Office suite.

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



_______________________________________________
OpenAFS-announce mailing list
OpenAFS-announce@openafs.org
https://lists.openafs.org/mailman/listinfo/openafs-announce

_______________________________________________
OpenAFS-announce mailing list
OpenAFS-announce@openafs.org
https://lists.openafs.org/mailman/listinfo/openafs-announce