[cifs-protocol] MS-SMB2: File.LastModificationTime updates for write IO vs setinfo

[Ralph Boehme]

Hello dochelp,

I'm seeking clarification on SMB server behaviour differences between
Windows versions 2016 and 2019 with regard to MS-FSA

  File.Last[Modification|Change|Access]Time

and

  Open.UserSet[Modification|Change|Access]Time


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 2.1.5.3 "Server Requests a Write":

  The object store MUST note that the file has been modified
  as specified in section 2.1.4.17 with Open equal to Open

2.1.4.17:

  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?

Thanks!
-slow

Network traces:
<https://www.samba.org/~slow/pcaps/delayed-mtime-write-vs-set-2handles-w2016.pcapng.gz>
<https://www.samba.org/~slow/pcaps/delayed-mtime-write-vs-set-2handles-w2019.pcapng.gz>