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
OpenPGP_signature.asc
Description: OpenPGP digital signature
_______________________________________________ cifs-protocol mailing list cifs-protocol@lists.samba.org https://lists.samba.org/mailman/listinfo/cifs-protocol
