Hi Ralph: When an oplock break happens on a durable handle, the handle is closed. In this case the oplock break in acknowledged internally and the contending create succeeds. This is the behavior you are observing.
I have filed a TDI to document this behavior in MS-SMB2. Please let me know if this does not answer your question. Regards, Obaid Farooqi Sr. Escalation Engineer | Microsoft -----Original Message----- From: Ralph Boehme <[email protected]> Sent: Sunday, August 31, 2025 9:54 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've uploaded the requested traces with sharemode=RW. Thanks! -slow On 8/25/25 4:13 AM, Obaid Farooqi wrote: > Hi Ralph: > Thanks for the traces. Unfortunately what I was thinking (second create > coming too soon) did not work. > In order for me to compare apples to apples, can you please make the share > mode in both case the same? > > In case of lease, the share mode is RW in first create and RWD in case > of second create For oplocks, you are doing just read in first create and RWD > in second create. > > Can you please do exactly the same sharing mode for oplocks? > > Regards, > Obaid Farooqi > Sr. Escalation Engineer | Microsoft > > -----Original Message----- > From: Obaid Farooqi > Sent: Tuesday, August 19, 2025 4:02 AM > To: Ralph Boehme <[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 Ralph: > In the first client, can you do a write or some other operation on the file > before disconnecting? > > Regards, > Obaid Farooqi > Sr. Escalation Engineer | Microsoft > > -----Original Message----- > From: Ralph Boehme <[email protected]> > Sent: Friday, August 15, 2025 12:34 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, > > looking again at the quoted section: > > On 8/14/25 9:28 PM, Obaid Farooqi wrote: >> I think the behavior you are observing is explained pretty well in >> section " 3.3.4.6 Object Store Indicates an Oplock Break". There is >> no consideration to open.IsPersistent when there is no connection >> available, as stated in specifications as follows: >> >> " 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. " > this says it will break to NONE, but what I see and reported is a break from > BATCH to SHARED. > > Additionally, a SHARED oplock is not downgraded at all, same for a EXCLUSIVE > oplock. > > I'm going to upload traces for these two additional cases. > > Maybe it's too late in the evening, but all three oplock break > scenarios > > S -> S > X -> X > B -> S > > don't seem to align with the spec. > > *scratches head* > > Thanks! > -slow _______________________________________________ cifs-protocol mailing list [email protected] https://lists.samba.org/mailman/listinfo/cifs-protocol
