Hi Obaid, ok, thanks!
But the text in the screenshot differs from the text you've send as new text?
In the screenshot it starts with "If Open.IsDurable is TRUE, Open.IsPersistent is FALSE and ..." which is different from the text in your earlier mail?If the text in red in the screenshot are indeed additions, then the behavior from the trace doesn't seem to match this?
Can you please clarify? Thanks! On 12/29/25 11:38 PM, Obaid Farooqi wrote:
Hi Ralph: Sorry, I messed up. The old verbiage should have been: ============= 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. ============= I have attached a picture with additions in red. Regards, Obaid Farooqi Sr. Escalation Engineer | Microsoft -----Original Message----- From: Ralph Boehme <[email protected]> Sent: Monday, December 29, 2025 4:48 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 tried very hard (including cmdline diff command) to find a difference between those two versions, but it seems there is none? However, realizing the difference in server handling between oplocks and leases (which has the additional clause "If Open.IsPersistent is TRUE and Lease.LeaseState is not SMB2_LEASE_READ_CACHING, the server MUST take no further action."), I guess observed behaviour matches the spec. I still think this makes Persistent Handles unusable with oplocks due to the danger of data corruption as the disconnected Persistent Handle is not protected from concurrent access and the client may have cached data. Thanks! On 11/7/25 10:21 PM, Obaid Farooqi wrote: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
OpenPGP_signature.asc
Description: OpenPGP digital signature
_______________________________________________ cifs-protocol mailing list [email protected] https://lists.samba.org/mailman/listinfo/cifs-protocol
