Hi Ralph: I want to live debug these two issues (oplocks with persistent handle and object name not found). Can you send me the code for the smbtorture test cases that reproduce these issues?
Regards, Obaid Farooqi Sr. Escalation Engineer | Microsoft -----Original Message----- From: Obaid Farooqi Sent: Sunday, August 24, 2025 9:14 PM To: 'Ralph Boehme' <[email protected]> Cc: '[email protected]' <[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: 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
