[cifs-protocol] 119101121001349 MS-SMB2: File.LastModificationTime updates for write IO vs setinfo
srenaden at microsoft.com
Fri Oct 11 18:54:39 UTC 2019
Dochelp in Bcc
Casemail in Cc
Hello Ralph, I will be assisting you with your question. I am currently researching the problem and will provide you with an update soon. Thank you for your patience.
Microsoft Windows Open Specifications
From: Ralph Boehme <slow at samba.org>
Sent: Friday, October 11, 2019 9:36 AM
To: Interoperability Documentation Help <dochelp at microsoft.com>
Cc: cifs-protocol at lists.samba.org
Subject: MS-SMB2: File.LastModificationTime updates for write IO vs setinfo
I'm seeking clarification on SMB server behaviour differences between Windows versions 2016 and 2019 with regard to MS-FSA
Comparing Windows 2016 and Windows 2019 acting as SMB servers I see a difference in behaviour for the following scenario:
A) SMB2 CREATE testfile "foo" -> file-handle H1
B) Write some data to handle H1
C) Compound operation (different connection):
- open second handle on "foo" -> H2
- set the ModificationTime to some value X
- close H2
D) close H1
E) query ModificationTime of file "foo" (SMB2 CREATE+CLOSE)
What is the expected result for ModificationTime in step E?
Windows 2016 returns the time of event D. But Windows 2019 returns the value of X set in C.
Why are they different? What is the correct behaviour? Both? Can you please point me at the relevant docs from which this behaviour difference would follow?
According to MS-FSCC <87> "...the filesystem updates the timestamp value in an implementation dependent manner".
Deducing from that the timestamp update triggered by operation B can be performed any time between B and D, which means there's an ordering dependency on C which will indeed result in different visible behaviour.
MS-FSA on the other hand says in 126.96.36.199 "Server Requests a Write":
The object store MUST note that the file has been modified
as specified in section 188.8.131.52 with Open equal to Open
If Open.UserSetModificationTime is FALSE, set
Open.File.LastModificationTime to the current system time.
In the above scenario Open.UserSetModificationTime is indeed FALSE so Open.File.LastModificationTime should be set *without delay* (?) to the current system time which isn't the case in the scenario with Windows
2016 where the timestamp is apparently updated only after C.
Can you please point me at the relevant specs that explain the scenario?
More information about the cifs-protocol