3.3.5.14.1 Processing Unlocks

For each SMB2_LOCK_ELEMENT entry in the Locks array, if either SMB2_LOCKFLAG_SHARED_LOCK or SMB2_LOCKFLAG_EXCLUSIVE_LOCK is set, the server MUST fail the request with STATUS_INVALID_PARAMETER and stop processing further entries in the Locks array, and all successfully processed unlock operations will not be rolled back.

If SMB2_LOCKFLAG_FAIL_IMMEDIATELY is set, the server MAY<311> ignore this flag.

The server MUST issue the byte-range unlock request to the underlying object store using Open.LocalOpen, and passing the Offset and Length (in bytes) from the SMB2_LOCK_ELEMENT entry.<312> If the unlock operation fails, the server MUST fail the operation with the error code received from the object store and stop processing further entries in the Locks array.

If the unlock operation succeeds, the server MUST decrease Open.LockCount by 1. If there are remaining entries in the Locks array, the server MUST continue processing the next entry in the Locks array as specified above.

If the unlock operation succeeds and there are no remaining entries in the Locks array, Connection.Dialect is "2.1" or belongs to the SMB 3.x dialect family, and Open.IsResilient or Open.IsPersistent is TRUE, the server MUST set the lock sequence number in Open.LockSequenceArray through the following step to indicate that the unlock request with LockSequence has been successfully processed by the server:

  1. If an entry is found via the lock request process described in the numbered list in section 3.3.5.14, the server MUST set Valid to TRUE and save LockSequenceNumber into SequenceNumber of the corresponding entry.

If the unlock operation succeeds and there are no remaining entries in the Locks array, the server initializes an SMB2 LOCK Response following the syntax specified in section 2.2.27, which then MUST be sent to the client.

Show: