Hi Obaid,

I tried very hard (including cmdline diff command) to find a difference between those two versions, but it seems there is none?

However, realizing the difference in server handling between oplocks and leases (which has the additional clause "If Open.IsPersistent is TRUE and Lease.LeaseState is not SMB2_LEASE_READ_CACHING, the server MUST take no further action."), I guess observed behaviour matches the spec.

I still think this makes Persistent Handles unusable with oplocks due to the danger of data corruption as the disconnected Persistent Handle is not protected from concurrent access and the client may have cached data.

Thanks!

On 11/7/25 10:21 PM, Obaid Farooqi wrote:
Hi Ralph:
In an upcoming release, the MS-SMB2 will have the following 
modifications/changes:

3.3.4.6 Object Store Indicates an Oplock Break
=======================================

Old verbiage
-----------------
If Open.IsDurable is TRUE and the notification could not be sent on any 
connection, the server MUST complete the oplock break from the underlying 
object store with SMB2_OPLOCK_LEVEL_NONE as the new oplock level and MUST set 
Open.OplockLevel to SMB2_OPLOCK_LEVEL_NONE and Open.OplockState to None. The 
server MUST close the Open as specified in section 3.3.4.17.
------------------

Modified
-------------
If Open.IsDurable is TRUE and the notification could not be sent on any 
connection, the server MUST complete the oplock break from the underlying 
object store with SMB2_OPLOCK_LEVEL_NONE as the new oplock level and MUST set 
Open.OplockLevel to SMB2_OPLOCK_LEVEL_NONE and Open.OplockState to None. The 
server MUST close the Open as specified in section 3.3.4.17.
--------------

Please let me know if this does not answer your question.

Also let me know if this removes your objection that you expressed below.


Regards,
Obaid Farooqi
Sr. Escalation Engineer | Microsoft

-----Original Message-----
From: Ralph Boehme <[email protected]>
Sent: Sunday, September 14, 2025 12:44 PM
To: Obaid Farooqi <[email protected]>
Cc: [email protected]; Microsoft Support <[email protected]>
Subject: Re: [EXTERNAL] MS-SMB2: Disconnected Persistent Handle with batch 
oplock not protected from contending open with write access - 
TrackingID#2508100040000955

Hi Obaid,

ok, thanks, that explains one part of the behavioral difference compared to 
leases.

The more serious one is: isn't this violating MS-SMB2 3.3.5.9 Receiving an SMB2 
CREATE Request footnote 300?

     If Open.ClientGuid is not equal to the ClientGuid of the connection
     that received this request, Open.Lease.LeaseState is equal to RWH,
     or Open.OplockLevel is equal to SMB2_OPLOCK_LEVEL_BATCH, Windows-based
     servers will attempt to break the lease/oplock and return
     STATUS_PENDING to process the create request asynchronously.
     Otherwise, if Open.Lease.LeaseState does not include
     SMB2_LEASE_HANDLE_CACHING and Open.OplockLevel is not equal to
     SMB2_OPLOCK_LEVEL_BATCH, Windows-based servers return
     STATUS_FILE_NOT_AVAILABLE.

So in my overall understanding, in this scenario could either directly fail 
with STATUS_FILE_NOT_AVAILABLE, or it could process request asynchronously and 
return STATUS_PENDING.

But just discarding the batch oplock and succeeding the contending open looks 
like a serious bug.

Thanks!
-slow


Attachment: OpenPGP_signature.asc
Description: OpenPGP digital signature

_______________________________________________
cifs-protocol mailing list
[email protected]
https://lists.samba.org/mailman/listinfo/cifs-protocol

Reply via email to