Hi Ralph, We have created SR 2409060040001453 to address the issue of compound responses getting split:
Details: [Related to SR 2409010040000238] Another presumable undocumented behavior is that in a series of compound CREATE + NOTIFY requests, the CREATE response and the PENDING response for the NOTIFY are sent in two different SMB2 response packets. 3.3.5.2.7.2 Handling Compounded Related Requests only has a SHOULD here: When all operations are complete, the responses SHOULD be compounded into a single response to return to the client. In my testing NOTIFY seems to be the only request that triggers this splitting of compound requests into separate responses, but I certainly didn't cover all cases and wonder if there may be other scenarios where this happens. From hard lessons learned in the past, we know that such subtle differences sometimes make the difference between a happy client and a broken one, so I'd highly appreciate some clarification on this one too. Best regards, Jeff McCashland (He/him) | Senior Escalation Engineer | Microsoft Corporation Phone: +1 (425) 703-8300 x38300 | Hours: 9am-5pm | Time zone: (UTC-08:00) Pacific Time (US and Canada) Local country phone number found here: http://support.microsoft.com/globalenglish | Extension 1138300 ________________________________ From: Jeff McCashland (He/him) <je...@microsoft.com> Sent: Thursday, September 5, 2024 11:01 AM To: Ralph Boehme <s...@samba.org> Cc: cifs-protocol@lists.samba.org <cifs-protocol@lists.samba.org>; Microsoft Support <supportm...@microsoft.com> Subject: Re: [EXTERNAL] SMB2 compound requests handling - TrackingID#2409010040000238 [Michael to BCC] Hi Ralph, I will dig into the traces you provided, and let you know what I find. Best regards, Jeff McCashland (He/him) | Senior Escalation Engineer | Microsoft Corporation Phone: +1 (425) 703-8300 x38300 | Hours: 9am-5pm | Time zone: (UTC-08:00) Pacific Time (US and Canada) Local country phone number found here: http://support.microsoft.com/globalenglish | Extension 1138300 ________________________________ From: Michael Bowen <mike.bo...@microsoft.com> Sent: Saturday, August 31, 2024 8:02 PM To: Ralph Boehme <s...@samba.org> Cc: cifs-protocol@lists.samba.org <cifs-protocol@lists.samba.org>; Microsoft Support <supportm...@microsoft.com> Subject: RE: [EXTERNAL] SMB2 compound requests handling - TrackingID#2409010040000238 Hi Ralph, Thanks for your inquiry. I've created case 2409010040000238 to track this issue. One of our team members will follow up with you soon. Best regards, Michael Bowen Sr. Escalation Engineer - Microsoft® Corporation -----Original Message----- From: Ralph Boehme <s...@samba.org> Sent: Saturday, August 31, 2024 8:33 AM To: Interoperability Documentation Help <doch...@microsoft.com> Cc: cifs-protocol@lists.samba.org Subject: [EXTERNAL] SMB2 compound requests handling Hello dochelp! We recently debugged an issue with macOS client getting an error from Samba when renaming a file. I tracked this down to a difference in behaviour when receing a compound related request chain of CREATE + SETINFO(rename) + CLOSE. The rename triggers a lease break of a handle lease of another open on the same file by another client. In Samba we treat the SETINFO(rename) that has to wait for the lease break processing as an async request and then fail the request as we implement the restriction from 3.3.5.2.7 Handling Compounded Requests: The server MAY<262> fail requests in a compound chain which require asynchronous processing. Hence the above compound related request chain of CREATE + SETINFO(rename) + CLOSE fails with NT_STATUS_INTERNAL_ERROR and the client is unhappy. The same request works against Windows, apparently because a SETINFO(rename) that triggers a lease break is allowed in any position in a compound chain by Windows server. So both a CREATE and SETINFO(rename) are allowed in any position of a compound chain, which is a bit confusing since both request should trigger the exact same async processing and <262> only talks about CREATE. Additionally another difference is that for the rename no async interim STATUS_PENDING response is sent which seems to violate 3.3.5.2.7.2 Handling Compounded Related Requests: When an operation requires asynchronous processing, all the subsequent operations MUST also be processed asynchronously. The server MUST send an interim response for all such operations as specified in section 3.3.4.2. Is this by design? Did I miss the bits in MS-SMB2 that describe this? What is the general rule? Are there other special cases? Another presumable undocumented behavior is that in a series of compound CREATE + NOTIFY requests, the CREATE response and the PENDING response for the NOTIFY are sent in two different SMB2 response packets. 3.3.5.2.7.2 Handling Compounded Related Requests only has a SHOULD here: When all operations are complete, the responses SHOULD be compounded into a single response to return to the client. In my testing NOTIFY seems to be the only request that triggers this splitting of compound requests into seperate responses, but I certainly didn't cover all cases and wonder if there may be other scenarios where this happens. From hard lessons learned in the past, we know that such subtle differences sometimes make the difference between a happy client and a broken one, so I'd highly appreciate some clarification on this one too. :) Attaching two network traces that cover both scenarios taken against a Windows server. I'll be at SDC, if you like we can discuss this there. :) Thanks! -slow
_______________________________________________ cifs-protocol mailing list cifs-protocol@lists.samba.org https://lists.samba.org/mailman/listinfo/cifs-protocol
