[DocHelp to Bcc] Hi Jeremy,
Thank you for your request. The case number 2209220040008649 has been created for this inquiry. One of our team members will follow-up with you soon. Regards, Kristian Kristian Smith Support Escalation Engineer Windows Open Spec Protocols Office: (425) 421-4442 [email protected] -----Original Message----- From: Jeremy Allison <[email protected]> Sent: Thursday, September 22, 2022 4:02 PM To: Interoperability Documentation Help <[email protected]> Cc: [email protected]; [email protected]; metze <[email protected]> Subject: [EXTERNAL] Seeking clarification of SMB3 async behavior in a compound request. Hi Dochelp, I'm seeking clarify on the behavior of compound requests going async in SMB3. MS-SMB2 states in: ------------------------------------------------------- 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. ------------------------------------------------------- But this doesn't appear to be the case against Windows 2022. I have a set of tests that do the following to force asynchronous operation in compound requests against Windows 2022 (thanks to Metze for the ideas for these). Test #1 Opendir foo <- returns foo-handle notify on foo-handle create foo/bar notify recv delete foo/bar Compound -------------- notify on foo-handle close (compound handle) -------------- When the server sees the compound request starting with the notify in this test it should have a pending FILE_DELETED notify return queued up and ready to return for the compound notify, so this test should not need to go async at all. However, Windows 2022 returns NT_STATUS_INTERNAL_ERROR for the compound notify request. Test #2 Opendir foo <- returns foo-handle notify on foo-handle create foo/bar notify recv delete foo/bar Compound -------------- getinfo foo-handle notify (compound handle) close (compound handle) -------------- This test is the same as test #1, with the addition of the getinfo foo-handle in the compound to determine how Windows behaves when a request that might go async is in the middle of the compound stream. When the server sees the compound request starting with the notify in this test it should have a pending DELETE-FILE notify return queued up and ready to return for the compound notify, so this test should not need to go async at all. However, Windows 2022 returns NT_STATUS_INTERNAL_ERROR for the compound notify request. Test #3 Opendir foo <- returns foo-handle notify on foo-handle create foo/bar notify recv Compound -------------- notify foo-handle close (compound handle) -------------- When the server sees the compound request starting with the notify in this test it should have no pending requests to return, and so the compound notify should be forced to go async. However, Windows 2022 returns NT_STATUS_INTERNAL_ERROR for the compound notify request. Test #4 Opendir foo <- returns foo-handle notify on foo-handle notify foo create foo/bar notify recv Compound -------------- getinfo foo-handle notify (compound handle) close (compound handle) -------------- This test is the same as test #1, with the addition of the getinfo foo-handle in the compound to determine how Windows behaves when a request that might go async is in the middle of the compound stream. When the server sees the compound notify request in this test it should have no pending requests to return, and so the compound notify should be forced to go async. However, Windows 2022 returns NT_STATUS_INTERNAL_ERROR for the compound notify request. It appears Windows 2022 might treat SMB2_OP_NOTIFY differently to other requests in a compound but I can't find this documented anywhere. I can send test patches against Samba smbtorture to show reproduction of this locally, or can send in packet traces for any or all of these tests. Thanks ! Jeremy. _______________________________________________ cifs-protocol mailing list [email protected] https://lists.samba.org/mailman/listinfo/cifs-protocol
