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

[Sreekanth Nadendla]

Hello Ralph, I just wanted to let you know that we are still researching this issue. I will update you as soon as I have the information to share with you. 

Regards,
Sreekanth Nadendla
Microsoft Windows Open Specifications


-----Original Message-----
From: Sreekanth Nadendla 
Sent: Friday, October 11, 2019 2:55 PM
To: Ralph Boehme <slow at samba.org>
Cc: cifs-protocol at lists.samba.org; support <support at mail.support.microsoft.com>
Subject: 119101121001349 MS-SMB2: File.LastModificationTime updates for write IO vs setinfo

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.

Regards,
Sreekanth Nadendla
Microsoft Windows Open Specifications


-----Original Message-----
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

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%7Csrenaden%40microsoft.com%7Ce5bcc614d5a64ba9a19d08d74e4fe951%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637063977442238897&sdata=XsfGDLBBtXbA1r0RdCNsSOWfuCWzUR0W88xzBs5RWfk%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%7Csrenaden%40microsoft.com%7Ce5bcc614d5a64ba9a19d08d74e4fe951%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637063977442238897&sdata=zJGsFH8WZlczYGelqUPK4SBB%2FfcJ8P1h3kKmp7rtNN8%3D&reserved=0>