[cifs-protocol] SMB_COM_LOCK_BYTE_RANGE lock conflict handling

[Volker Lendecke]

Hi, dochelp!

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
somewhere.

Thanks,

Volker

-- 
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...
Name: lock.cap
Type: application/vnd.tcpdump.pcap
Size: 10461 bytes
Desc: not available
URL: <http://lists.samba.org/pipermail/cifs-protocol/attachments/20190606/fb9d018d/lock.cap>