General Information =================== Releases of OpenAFS for Windows prior 1.5.62 may fail to store data to file servers. There are two issues that are addressed in the 1.5.62 release.
Problem 1. Failure to Store Portions of Unaligned Writes --------------------------------------------------------- By default, OpenAFS for Windows caches data in 4KB buffers. If the data being written starts at an offset from the beginning of the file that is not a multiple of the 4KB block size, then the cache manager will fail to store (offset % blocksize) bytes to the file server while at the same time marking the affected buffer as fully stored. Problem 2. Failure to Store Data to File Servers Lacking Large File Support ---------------------------------------------------------------------------- The AFS protocol as defined and implemented by Transarc/IBM did not include support for files with lengths greater than 2GB (2^31). OpenAFS extended the AFS protocol to support files up to (2^64) by adding two new RPCs (StoreData64 and FetchData64). The cache manager determines if a file server supports 64-bit file operations by attempting to perform the RPC and then falling back to the older 31-bit file operations if they are not supported. The result of this test is saved until the next time the file server sends an InitCallBackState RPC to the cache manager. If the first 64-bit file operation after the receipt of an InitCallBackState RPC is a StoreData64 RPC, the Windows cache manager would mark the server as having no 64-bit file support and would retry using the 31-bit StoreData RPC. However, it would fail to reset the number of bytes to be written to the file server prior to the StoreData RPC being issued. As a result, up to one StoreData64 RPC worth of data (aka one chunk) would not be stored to the file server even though the affected buffers are marked fully stored. Affected and Non-Affected Software ================================== Problem 1 affects all releases of OpenAFS for Windows since the original IBM contribution. This problem is independent of the capabilities of the file server. Problem 2 affects releases of OpenAFS for Windows from 1.5.3 to 1.5.61. The problem can only occur in conjunction with file servers that do not support 64-bit file operations. These include all IBM AFS file servers and OpenAFS file servers prior to 1.3.70 (and those which were explicitly built without large file support). Additional Factors ================== The chances of data loss as a result of Problem 2 are exacerbated by firewalls and network address translators that have short lifetimes for UDP port mappings. When a port mapping is dropped the cache manager is forced to establish a new Rx connection to the file server. In response the file server may issue an InitCallBackState RPC forcing any knowledge of the file server's 64-bit file support to be forgotten. The InitCallBackState RPC received by the cache manager does not have to originate with a file server lacking 64-bit file support in order for it the result in the loss of file server capability knowledge. As the callback channel is unauthenticated, any user with the ability to issue InitCallBackState RPCs to the client can attempt to force data loss to occur. Workarounds =========== There are no workarounds to these problems other than upgrading: * the Windows client to the OpenAFS 1.5.62 or later release, or * upgrading all file servers to the OpenAFS 1.3.70 or later release
smime.p7s
Description: S/MIME Cryptographic Signature
