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

[Obaid Farooqi]

Hi Ralph:
Thanks for the additional information.

Regards,
Obaid Farooqi
Escalation Engineer | Microsoft

________________________________________
From: Ralph Boehme
Sent: Monday, March 10, 2025 4:34 AM
To: Sreekanth Nadendla
Cc: Microsoft Support; cifs-protocol at lists.samba.org
Subject: Re: MS-FSA 2.1.4.17 Algorithm for Noting That a File Has Been Modified - TrackingID#2503100040000894

Hi Sreekanth,

...adding cifs-protocol to cc which I forgot to add in my initial mail...

On a related note the server is also unexpectedly updating timestamps when a request is processed to set the filesize to the existing size, cf packet 47 which sets the filesize to 0, the current size after the file has just been created, and packet 50 which shows updated timestamps even though MS-FSA 2.1.5.15.4 FileEndOfFileInformation has the same check as FileAllocationInformation mentioned in the initial mail:

   If Open.Stream.Size is equal to InputBuffer.EndOfFile,
   the operation MUST return STATUS_SUCCESS at this point.

According to 2.1.5.15.4, 2.1.4.17 must be skipped, while leases must still be broken, which I find also counterintuitive.

Thanks!
-slow


On 3/10/25 4:08 AM, Sreekanth Nadendla wrote:
> 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