Steven, I completed the investigation on the behavior described in your e-mail. It is a normal behavior that has been documented in the MS-SMB2 document. The following is the explanation:
The server processing logic is described in details in "3.3.5.14
Receiving an SMB2 Lock Request". You are right that the both unlock and
lock requests cannot be mixed in the same SMB2_LOCK request. The server
processes the Locks array in SMB2_LOCK request as either a series of locks or
a series of unlocks based on if the initial SMB2_LOCK entry has
SMB2_LOCFLAG_UNLOCK bit set or not. Any combination of unlocks and locks in
the same SMB2_LOCK request will fail with STATUS_ INVALID_PARAMETER.
As per 3.3.5.14.1, when the lock array in SMB_LOCK is considered as a series
of unlocks, for any SMB2_LOCK entry, 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.
For the network traffic you mentioned, we can see that
1) Packet 27-28: A single lock request succeeding on range 0-10.
ANS: Single lock succeeded as expected.
2) Packet 29-30: A lock request with unlock(0-10) and lock(10-10) failing
with INVALID_PARAMETER.
ANS: Since the initial SMB2_LOCK in the locks array has
SMB2_LOCKFLAG_UNLOCK bit set, server MUST process the lock array as a series of
unlocks.(3.3.5.14) and the logic in 3.3.5.14.1 will be applied. Because the
second lock in the Locks array has SMB2_LOCKFLAG_SHARED_LOCK set, the server
fails with STATUS_INVALID_PARAMETER. But the first unlock request has been
processed and will not be rolled back.
3) Packet 31-32: A lock request with lock(0-10) and lock(10-10)
succeeding, showing that the previous request, though it returned an error,
succeeded in unlocking.
ANS: This is expected since the unlock for range (0-10) succeeded in
2).
If you have further questions regarding this behavior , please let us
know.
Thanks!
--------------------------------------------------------------------
Hongwei Sun - Sr. Support Escalation Engineer
DSC Protocol Team, Microsoft
[email protected]<mailto:[email protected]>
Tel: 469-7757027 x 57027
---------------------------------------------------------------------
From: Steven Danneman [mailto:[email protected]]
Sent: Monday, November 30, 2009 5:58 PM
To: Interoperability Documentation Help; [email protected];
[email protected]
Subject: SMB2 mixed lock & unlock requests in a single SMB_LOCK request
Hello,
I've come across another SMB2 locking issue that I can't find explicit
documentation for in MS-SMB2 (v18.0).
My first question, is whether a single SMB_LOCK request can contain both unlock
and lock requests as the LockingAndX command type in SMBv1 could? The MS-SMB2
document hints that the answer to this question is "no" but it doesn't seem to
explicitly state it anywhere.
Section 2.2.26 states: "The SMB2 LOCK Request packet is sent by the client to
either lock or unlock portions of a file."
This statement is ambiguous as to whether the "or" is inclusive or exclusive.
In my testing, sending both lock and unlock requests in a single SMB2 locking
request returns a STATUS_INVALID_PARAMETER. However, if the requests are
ordered such that a unlock structure come first, the unlock request seems to
succeed.
The attached pcap, against W2K8R2 shows:
1) Packet 27-28: A single lock request succeeding on range 0-10.
2) Packet 29-30: A lock request with unlock(0-10) and lock(10-10) failing with
INVALID_PARAMETER.
3) Packet 31-32: A lock request with lock(0-10) and lock(10-10) succeeding,
showing that the previous request, though it returned an error, succeeded in
unlocking.
It seems to me the server behavior should be to return STATUS_INVALID_PARAMETER
without completing any of the lock/unlock requests when they are mixed. Both
the fact that this isn't allowed, and the W2K8R2 behavior deviation should be
documented.
Thanks,
Steven Danneman | Software Development Engineer
Isilon Systems P +1-206-315-7500 F +1-206-315-7501
www.isilon.com<http://www.isilon.com>
[cid:[email protected]] How breakthroughs begin. (tm)
<<inline: image001.gif>>
_______________________________________________ cifs-protocol mailing list [email protected] https://lists.samba.org/mailman/listinfo/cifs-protocol
