[cifs-protocol] SMB_COM_LOCK_BYTE_RANGE lock conflict handling [REG:119060625002185]
obaidf at microsoft.com
Mon Jun 10 23:27:55 UTC 2019
I am looking into this and will be in touch as soon as I have an answser.
Escalation Engineer | Microsoft
Exceeding your expectations is my highest priority. If you would like to provide feedback on your case you may contact my manager at ramagane at Microsoft dot com
From: Tom Jebo <tomjebo at microsoft.com>
Sent: Thursday, June 6, 2019 12:11 PM
To: Volker.Lendecke at SerNet.DE
Cc: cifs-protocol at lists.samba.org; support <support at mail.support.microsoft.com>
Subject: RE: SMB_COM_LOCK_BYTE_RANGE lock conflict handling [REG:119060625002185]
[dochelp to bcc]
[support mail to cc]
Thanks for the question. I have created case number 119060625002185 to track this issue and placed the number in the subject of this email. Please refer to it and leave it in the subject when communicating about this issue with our team. One of the Open Specifications team members will get back to you shortly.
Sr Escalation Engineer
Microsoft Open Specifications
From: Volker Lendecke <Volker.Lendecke at SerNet.DE>
Sent: Thursday, June 6, 2019 1:19 AM
To: Interoperability Documentation Help <dochelp at microsoft.com>
Cc: cifs-protocol at lists.samba.org
Subject: SMB_COM_LOCK_BYTE_RANGE lock conflict handling
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.
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 - https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.sernet.de&data=02%7C01%7Cobaidf%40microsoft.com%7C884c12a5b80643bd6c9408d6eaa206b6%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636954378962947874&sdata=TYchumZdbMEIqh9RVegzMbaeG5MmxnO2xbfHTJ6h5Kk%3D&reserved=0
More information about the cifs-protocol