HP UX Common Internet File System (CIFS) Client/Server Software manual

Mandatory Share Mode (Open Mode) locking applies to Windows clients only. File sharing issues arise when concurrent file access occurs between Windows clients and UNIX clients, PC-NFS clients, or on files that have been NFS-mounted. UNIX processes have no concept of Mandatory Share Mode locks. A key issue with sharing files between UNIX and

Windows is that a Windows client can hold a Mandatory Share Mode lock on a file, but a UNIX process can open the same file concurrently for write access, resulting in unacceptable risk of data corruption. CIFS/9000 has been enhanced to translate Windows Mandatory Share Mode locks into byte range locks, therefore providing locking interoperation with the UNIX advisory locking protocol and reducing the risk of data corruption.

Providing protection for Windows clients from UNIX/NFS concurrent file access is an important added-value feature for Windows-UNIX integration, but is not a comprehensive solution. There are Windows-UNIX integration products that can provide Windows client Mandatory Share Mode (open mode) locking protection from UNIX/NFS processes, even if they do not participate in the UNIX advisory locking protocol. However, if a UNIX/NFS application is not properly coded to lock files, then there is no way to protect other UNIX/NFS processes from concurrent file access data corruption. If data can be corrupted by UNIX/NFS concurrent file access, then providing Windows Share Mode (open mode) locking protection from those same UNIX/NFS processes (mixed-mode access) does not remove the element of risk from data corruption because the locking interoperability is not comprehensive system-wide3.

A future enhancement will protect Windows Clients with Mandatory Share Mode (open mode) locks from UNIX/NFS concurrent file access even if the UNIX/NFS process does not participate in the advisory locking protocol. This file locking interoperability issue is the focus of many claims by HP’s competitors. See section 8 and Appendix B.5 for more details.

5.2.BYTE RANGE LOCKING (programmatic) is implemented by the

Windows client calls to the LockFile and LockFileEx APIs. The smbd process honors the byte range lock by calling the UNIX fcntl function and invoking the UNIX byte range advisory locks on the file (see the UNIX topic above). Thus, if the Windows application sets byte range locks, CIFS/9000 can interoperate with UNIX processes utilizing advisory locking4. Windows client access (homogenous) will honor the CIFS/9000 byte range locks.

CIFS/9000 disables byte range locking with the “locking” parameter in the smb.conf file:

[share_name] locking = no

The default is “yes”. If locking is set to “no”, the byte range locks will appear to succeed on the Windows client, but the smbd will not actually apply the advisory locks to the file. When set to yes, the second open process blocks waiting for the release of the lock. Most applications expect the locking to be enabled (byte range locking) – don’t change it.

Strict locking changes the way byte range locking is enforced. By default, byte range locking is implemented when a Windows client application calls the LockFile or LockFileEx APIs. Byte range lock status is only checked when the application calls these APIs. Strict locking enables the smbd to check for byte range locks on every read and write access to a file. The

3See Appendix B.5

4See Appendix B.2

13