HP CIFS File Locking Interoperation

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

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 locking

. 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

See Appendix B.5

See Appendix B.2