[cifs-protocol] [EXTERNAL] Re: MS-FSA 2.1.4.17 Algorithm for Noting That a File Has Been Modified - TrackingID#2503100040000894

Mon Mar 17 17:36:35 UTC 2025

Hi Ralph:
Thanks for the trace. It confirms what I have already described in my previous email for changing file allocation. For end of file, my research also shows that time stamp is always updated with "modification".

As noted in MS-FSA, section 2.1.1.3:
"
- LastModificationTime: The time that identifies when the file contents were last modified in the
FILETIME format specified in [MS-FSCC] section 2.1.1.<15>
- LastChangeTime: The time that identifies when the file metadata or contents were last changed
in the FILETIME format specified in [MS-FSCC] section 2.1.1.<16>
"

In summary, 
When set info is called for FileEndOfFileInformation, even if new size is same as the old size, modification and change timestamps will be updated.

When set in is called for FileAllocationInformation, 
If (the new allocation size is less than the existing allocation)
	Set the modification time stamp (which will also update the change time, as noted above)
Else
	Update the LastChangeTime

I have filed a bug to update MS-FSA.
Please let me know if this does not answer your question.

Regards,
Obaid Farooqi
Escalation Engineer | Microsoft

-----Original Message-----
From: Ralph Boehme <slow at samba.org> 
Sent: Thursday, March 13, 2025 12:42 PM
To: Obaid Farooqi <obaidf at microsoft.com>
Cc: Microsoft Support <supportmail at microsoft.com>; cifs-protocol at lists.samba.org
Subject: Re: [EXTERNAL] Re: MS-FSA 2.1.4.17 Algorithm for Noting That a File Has Been Modified - TrackingID#2503100040000894

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 <slow at samba.org>
> Sent: Monday, March 10, 2025 9:51 PM
> To: Obaid Farooqi <obaidf at microsoft.com>
> Cc: Microsoft Support <supportmail at microsoft.com>; Interoperability 
> Documentation Help <dochelp at microsoft.com>
> 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 <srenaden at microsoft.com>
>> Sent: Sunday, March 9, 2025 10:09 PM
>> To: Ralph Boehme <slow at samba.org>
>> Cc: Microsoft Support <supportmail at microsoft.com>
>> 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
>>
> 