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
