[cifs-protocol] SMB_COM_LOCK_BYTE_RANGE lock conflict handling
Volker.Lendecke at SerNet.DE
Thu Jun 6 08:18:49 UTC 2019
Tom confirmed to me at SambaXP that I can still ask SMB1 questions,
despite him having nice SMB1 deprecation stickers on his laptop :-)
Attached find a network trace against Windows 2012 R2. I am interested
in the documentation for the difference between frames 28 and 35.
Frame 26 is a conflicting lock request for range 0xEEFFFFFF which is
replied to immediately with LOCK_NOT_GRANTED. Frame 35 is pretty much
the same query, but this time the reply is delayed by roughly 200
milliseconds and gives a different error: FILE_LOCK_CONFLICT.
Yes, this is a deprecated SMB_COM_LOCK_BYTE_RANGE, but this also
happens with SMB_COM_LOCKING_ANDX for the same lock ranges.
There's another case where we get a deferred FILE_LOCK_CONFLICT: When
trying repeatedly beating the same lock, the second and all subsequent
failures receive FILE_LOCK_CONFLICT with a timeout, both for
LOCK_BYTE_RANGE and LOCKING_ANDX. I can provide network traces for
that too if required.
My *guess* is that the 200msec delay is a server optimization for some
client application going mad, and the LOCK_NOT_GRANTED vs
FILE_LOCK_CONFLICT is simply a "bug" in the deferred response routine.
But I'd need to see that network-visible protocol documented
SerNet GmbH, Bahnhofsallee 1b, 37081 Göttingen
phone: 0551-370000-0, mailto:kontakt at sernet.de
Gesch.F.: Dr. Johannes Loxen und Reinhild Jung
AG Göttingen: HR-B 2816 - http://www.sernet.de
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 10461 bytes
Desc: not available
More information about the cifs-protocol