Hi Obaid,ahh, looks like I painted myself into a corner here with a test that grew more and more over time as I tried to cover more cases....
So I completely overlooked that by having the initial "non-changing" operations in the wrong order (increasing the filesize to 1 increases allocation size as you thankfully pointed out, so the subtest that was supposed to check behaviour when setting an unmodified allocation size was in fact decreasing it).
Thanks so much for spotting this! :)Attached is a pcap of the fixed test. The following deviations from MS-FSA remain:
- increasing allocation size changes ctime, not mtime (in Linux parlance)- setting eof or allocation size to the current value updates mtime and ctime respectively (according to MS-FSA it shouldn't)
Thanks! -slow On 3/12/25 10:33 PM, Obaid Farooqi wrote:
Hi Ralph: Thanks for the trace. First of all, A file's allocation size and end-of-file position are independent of each other, with the following exception: The end-of-file position must always be less than or equal to the allocation size. If the allocation size is set to a value that is less than the end-of-file position, the end-of-file position is automatically adjusted to match the allocation size. (https://learn.microsoft.com/en-us/windows-hardware/drivers/ddi/ntifs/ns-ntifs-_file_allocation_information) With that in mind, we can disregard packet 59. Now when you send packet 103, the file allocation size is 8. You are setting it to zero. That shrinks the file and as such both write time and change time is modified and allocation size is now zero. In packet 125, you increase the size to 4096. This will update the change time but will not change the write time. The method that changes the fileallocationInformation always changes time with the following conditions: If (file shrinks) Update the modification time Else Update the change time. Your test does not exercise "If Open.Stream.AllocationSize is equal to NewAllocationSize, the operation MUST return STATUS_SUCCESS." You may want to run it again with a value that is same as current allocation size. Based on my research, the change time will change even if new allocation size is same as the current allocation size. I have filed a bug against MS-FSA to update section 2.1.5.15.1. Please let me know if this does not answer your question. Regards, Obaid Farooqi Escalation Engineer | Microsoft -----Original Message----- From: Ralph Boehme <[email protected]> Sent: Monday, March 10, 2025 9:51 PM To: Obaid Farooqi <[email protected]> Cc: Microsoft Support <[email protected]>; Interoperability Documentation Help <[email protected]> Subject: [EXTERNAL] Re: MS-FSA 2.1.4.17 Algorithm for Noting That a File Has Been Modified - TrackingID#2503100040000894 Hi Obaid, here it is, same problems: - client sets eof=0 (same as before), packet 59 - server has updated writetime, packet 64 (wrong according to ms-fsa) - client sets allocsize=0 (same as before), packet 103 - server has updated changetime and writetime, packet 108 - client sets allocsize=4096 (modified), packet 125 - server has updated only changetime, packet 130 pcap attached. Thanks! -slow On 3/10/25 8:17 PM, Obaid Farooqi wrote:Hi Ralph: I'll help you with this issue and will be in touch as soon as I have an answer. How soon you think you can provide me with an SMB2/3 repro? I'll start my investigation but I'll greatly appreciate an SMB2/3 repro. That will help a great deal. Regards, Obaid Farooqi Escalation Engineer | Microsoft -----Original Message----- From: Sreekanth Nadendla <[email protected]> Sent: Sunday, March 9, 2025 10:09 PM To: Ralph Boehme <[email protected]> Cc: Microsoft Support <[email protected]> Subject: MS-FSA 2.1.4.17 Algorithm for Noting That a File Has Been Modified - TrackingID#2503100040000894 Dochelp in Bcc Hello Ralph, thank you for reporting this windows open specifications issue. We've created incident 2503100040000894 to investigate this question and one of our team members will contact soon to assist you. Regards, Sreekanth Nadendla Microsoft Windows Open Specifications ________________________________________ From: Ralph Boehme Sent: Sunday, March 9, 2025 3:16 PM To: Interoperability Documentation Help Subject: [EXTERNAL] MS-FSA 2.1.4.17 Algorithm for Noting That a File Has Been Modified Hello dochelp, I'm currently working on "modernizing" Samba's write-time update behaviour to match modern Windows implementations. Samba still implements delayed write-time updates found in old Windows versions like server 2003 (iirc). I'm puzzled by a particular behaviour seen when setting file allocation size against a Windows Server 2022. According to MS-FSA 2.1.5.15.1 FileAllocationInformation, the object store should skip updating timestamps if the requested allocation size matches the current allocation size: If Open.Stream.AllocationSize is equal to NewAllocationSize, the operation MUST return STATUS_SUCCESS. Otherwise, later in the algorithm 2.1.4.17 is called to modify the timestamps: The object store MUST note that the file has been modified as specified in section 2.1.4.17 with Open equal to Open. What I see on the wire however is: - client creates file (packet 34) - client requests current allocation size which is 0 (packet 46) - client does a bunch of tests setting the file size which we can ignore - last client query for write time returns "19:10:44.105454700 CET" in packet 64 - client sets allocation size to 0 (packet 73) - client queries timestamps and gets a new write time "19:10:44.362271100 CET" in packet 78 - client sets allocation size to 8192 in packet 87 - client queries timestamps and gets an unmodified write time "19:10:44.362271100 CET" in packet 92 - however, the change time has been updated to "19:10:44.627909500 CET" by the change of allocation size I can't align this observation with MS-FSA. Am I missing something? Can you explain this? Trace attached. Fwiw, the test is using SMB1 because I'm writing the test for both SMB1 and SMB2 and the SMB2 is yet to be done. Thanks a lot! -slow
ms-fsa-file-modified-allocsize+eofsize-fixed-wsrv2022-smb2.pcapng
Description: application/pcapng
OpenPGP_signature.asc
Description: OpenPGP digital signature
_______________________________________________ cifs-protocol mailing list [email protected] https://lists.samba.org/mailman/listinfo/cifs-protocol
