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

[Tom Jebo]

[dochelp to bcc]
[support mail to cc]

Hi,

Thanks for the question on ModificationTime in SMB. I have created case number 119101121001349 to track this issue and placed the number in the subject of this email. Please refer to it and leave it in the subject when communicating about this issue with our team. One of the Open Specifications team members will get back to you shortly.

Best regards,
Tom Jebo
Sr Escalation Engineer
Microsoft Open Specifications


-----Original Message-----
From: Ralph Boehme <slow at samba.org> 
Sent: Friday, October 11, 2019 6: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

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://nam06.safelinks.protection.outlook.com/?url=https:%2F%2Fwww.samba.org%2F~slow%2Fpcaps%2Fdelayed-mtime-write-vs-set-2handles-w2016.pcapng.gz&data=02%7C01%7Ctomjebo%40microsoft.com%7Ce5bcc614d5a64ba9a19d08d74e4fe951%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637063977441089742&sdata=JKIcWb%2Bc9tmCpy3UZ8h5RUwRTHkLIsRFjUz3jTorUBk%3D&reserved=0>
<https://nam06.safelinks.protection.outlook.com/?url=https:%2F%2Fwww.samba.org%2F~slow%2Fpcaps%2Fdelayed-mtime-write-vs-set-2handles-w2019.pcapng.gz&data=02%7C01%7Ctomjebo%40microsoft.com%7Ce5bcc614d5a64ba9a19d08d74e4fe951%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637063977441089742&sdata=0jC11qH77mYGAUlxItllzUp2KflM8CckZEF4O9y762E%3D&reserved=0>