[cifs-protocol] [EXTERNAL] Re: [REG:120030321000983] SMB2: opening file for READ_CONTROL doesn't trigger lease break

[Jeff McCashland]

[-support]

Hi Ralph,

We've updated [MS-FSA] section 2.1.4.12 "Algorithm to Check for an Oplock Break" for the next release accordingly:

2.1.4.12 Algorithm to Check for an Oplock Break
The algorithm uses the following local variables:
§ OPERATION_MASK – a constant that MUST contain the following value:
	§ (LEVEL_ONE_OPLOCK|LEVEL_TWO_OPLOCK|BATCH_OPLOCK|READ_CACHING|WRITE_CACHING|HANDLE_CACHING)
Pseudocode for the algorithm is as follows:
§ Switch (Operation):
§ Case OPEN, as specified in section 2.1.5.1:
	§ If (((OpParams.DesiredAccess contains no flags other than FILE_READ_ATTRIBUTES, FILE_WRITE_ATTRIBUTES, READ_CONTROL, or SYNCHRONIZE) and (Oplock.State anded with OPERATION_MASK) contains no flags other than READ_CACHING, WRITE_CACHING, or HANDLE_CACHING)) or ((OpParams.DesiredAccess contains no flags other than FILE_READ_ATTRIBUTES, FILE_WRITE_ATTRIBUTES or SYNCHRONIZE) and (Oplock.State anded with OPERATION_MASK) contains no flags other than LEVEL_TWO_OPLOCK, LEVEL_ONE_OPLOCK or BATCH_OPLOCK))), the algorithm returns at this point. 
	§ EndIf

Hope that helps!

Best regards,
Jeff McCashland | Senior Escalation Engineer | Microsoft Protocol Open Specifications Team 
Phone: +1 (425) 703-8300 x38300 | Hours: 9am-5pm | Time zone: (UTC-08:00) Pacific Time (US and Canada)
Local country phone number found here: http://support.microsoft.com/globalenglish | Extension 1138300
We value your feedback.  My manager is Jeremy Chapman (jeremyc), +1 (469) 775-2475

-----Original Message-----
From: Jeff McCashland 
Sent: Wednesday, March 4, 2020 9:09 AM
To: Ralph Boehme <slow at samba.org>
Cc: cifs-protocol at lists.samba.org; support <support at mail.support.microsoft.com>
Subject: RE: [cifs-protocol] [EXTERNAL] Re: [REG:120030321000983] SMB2: opening file for READ_CONTROL doesn't trigger lease break

Hi slow,

Thank you for the trace!

That's not my call and will be verified when the change request is worked on. However, commentary in the code from Win7 days suggests it is by design. 

Best regards,
Jeff McCashland | Senior Escalation Engineer | Microsoft Protocol Open Specifications Team
Phone: +1 (425) 703-8300 x38300 | Hours: 9am-5pm | Time zone: (UTC-08:00) Pacific Time (US and Canada) Local country phone number found here: http://support.microsoft.com/globalenglish | Extension 1138300 We value your feedback.  My manager is Jeremy Chapman (jeremyc), +1 (469) 775-2475

-----Original Message-----
From: Ralph Boehme <slow at samba.org>
Sent: Wednesday, March 4, 2020 6:20 AM
To: Jeff McCashland <jeffm at microsoft.com>
Cc: cifs-protocol at lists.samba.org; support <support at mail.support.microsoft.com>
Subject: Re: [cifs-protocol] [EXTERNAL] Re: [REG:120030321000983] SMB2: opening file for READ_CONTROL doesn't trigger lease break

HI Jeff,

Am 3/4/20 um 10:53 AM schrieb Ralph Boehme via cifs-protocol:
> Am 3/3/20 um 10:23 PM schrieb Jeff McCashland:
>> However, note that legacy Oplocks do break on READ_CONTROL. If I understand our source code correctly, Leases never broke on READ_CONTROL, but we didn't catch the variance in the doc. 
> 
> I was afraid that this would be the case. :)
> 
> Just to be sure, I'll rewrite the testcase with oplocks instead of leases.

confirmed, trace attached (packets 123 ff). Are we sure this behaviour is by design and not a bug?

Thanks!
-slow

-- 
Ralph Boehme, Samba Team                https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fsamba.org%2F&data=02%7C01%7Cjeffm%40microsoft.com%7C556db01e42714d7d529408d7c0472de0%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637189284265492194&sdata=0Emcz%2F7Wr%2FVLPhNLRced%2Bq744meKQiZ8mY80qrdnCg4%3D&reserved=0
Samba Developer, SerNet GmbH   https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fsernet.de%2Fen%2Fsamba%2F&data=02%7C01%7Cjeffm%40microsoft.com%7C556db01e42714d7d529408d7c0472de0%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637189284265492194&sdata=fmgYg6hvC9FBCtA0KRCAfdJytKFegwsIGKQ6627%2FnSM%3D&reserved=0
GPG-Fingerprint   FAE2C6088A24252051C559E4AA1E9B7126399E46