Hi Ralph: Sorry, I messed up. The old verbiage should have been: ============= If 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. ============= I have attached a picture with additions in red.
Regards, Obaid Farooqi Sr. Escalation Engineer | Microsoft -----Original Message----- From: Ralph Boehme <[email protected]> Sent: Monday, December 29, 2025 4:48 AM 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, 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 >
_______________________________________________ cifs-protocol mailing list [email protected] https://lists.samba.org/mailman/listinfo/cifs-protocol
