Hi Ralph: I'll look into it and will be in touch as soon as I have an answer.
Regards, Obaid Farooqi Sr. Escalation Engineer | Microsoft -----Original Message----- From: Kristian Smith <[email protected]> Sent: Sunday, August 10, 2025 11:26 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 [DocHelp to Bcc] Hi Slow, Thanks for reaching out with your Persistent Handle question. I've created case 2508100040000955 to track the issue. One of our engineers will investigate and be in touch soon. Regards, Kristian Smith Support Escalation Engineer | Microsoft® Corporation Email: [email protected] -----Original Message----- From: Ralph Boehme <[email protected]> Sent: Sunday, August 10, 2025 7:46 AM To: Interoperability Documentation Help <[email protected]> Cc: [email protected] Subject: [EXTERNAL] MS-SMB2: Disconnected Persistent Handle with batch oplock not protected from contending open with write access Hello dochelp! Here comes another Persistent Handle related question... :) While initially testing and implementing Persistent Handle with various leases levels, just today I also drilled into Windows server behaviour when contending Persistent Handle with various oplock levels. It seems with when using oplocks, the Persistent Handle is not sufficiently protected against contending opens. I see the following expected behaviour when using leases: 1. Client 1: open file with lease=RWH, sharemode=RW 2. Client 1: TCP disconnect 3. Client 2: open file with RW access -> STATUS_PENDING, the open gets deferred until step 8 below 4. Client 1: reconnect TCP and SMB 5. Client 1: reconnect open 6. Server to client 1: lease break from RWH to RH 7. Client 1: lease break ack 8. Server to client 2: open succeeds Iow, the contending open is defferred as long as the PH is disconnected and the lease break is not acked. Not so much with oplocks: 1. Client 1: open file with a batch oplock, sharemode=RW 2. Client 1: TCP disconnect 3. Client 2: open file with RW access -> STATUS_PENDING, the open is briefly deferred, but then succeeds in step 4: 4. Server to client 2: open succeeds 5. Client 1: reconnect TCP and SMB 6. Client 1: reconnect open, batch oplock was downgraded to a level-ii oplock Is this expected behaviour? As afaict Persistent Handles are not really covered my MS-FSA, I'm using the SDC presentation "SMB 2.2 : Bigger, Faster, Scalier" from 2011 as guidance which states Exclusive (W) leases are preserved via blocking new creates from other clients. on page 47. It doesn't explicitly mention oplocks though... I can share network traces of both scenarios. Thanks! -slow _______________________________________________ cifs-protocol mailing list [email protected] https://lists.samba.org/mailman/listinfo/cifs-protocol
