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
