[cifs-protocol] [REG:119101421001093] MS-SMB2/FSA: File.LastModificationTime, update "lost" against Windows 2019

[Bryan Burgin]

[-Dochelp to bcc]
[+Support]

Hi Ralph,

Thank you for your question.  We created SR 119101421001093 to track your issue.  An engineer from the protocols team will contact you soon.

Bryan



-----Original Message-----
From: Ralph Boehme <slow at samba.org> 
Sent: Monday, October 14, 2019 9:57 AM
To: Interoperability Documentation Help <dochelp at microsoft.com>
Cc: cifs-protocol at lists.samba.org
Subject: MS-SMB2/FSA: File.LastModificationTime, update "lost" against Windows 2019

Hello dochelp,

I'm seeking clarification with regard to behaviour of MS-FSA File.LastModificationTime over SMB2.

Scenario
========

A) SMB client creates testfile -> handle H1

B) Client queries LastModificationTime with SMB2 GETINFO

C) Client writes to handle H1

D) 1 s delay

E) Close H1 with SMB2_CLOSE_FLAG_POSTQUERY_ATTRIB set

F) Re-open testfile, query timestamps, close (just to verify values from close response from step E).

Results
=======

Against a Windows 2016 server the testfile's modification time is updated in step E (packet 32) compared to the time from step B.

<https://nam06.safelinks.protection.outlook.com/?url=http:%2F%2Fwww.samba.org%2F~slow%2Fpcaps%2Fw2016-smb2-create-delay-getinfo-write-close.pcapng&data=02%7C01%7Cbburgin%40microsoft.com%7Cbf4aa31832ea4dc652e208d750c79be3%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637066690559680175&sdata=WvJXsYQoNRZ1II1S9nKa07NtbYiRBQ5pgz%2BtwK3tyvc%3D&reserved=0>

Against a Windows 2019 server the testfile's modification time remains unmodified across steps E and F compared to step B (packets 80+94). In other words: the write didn't trigger any update to File.LastModificationTime.

<https://nam06.safelinks.protection.outlook.com/?url=http:%2F%2Fwww.samba.org%2F~slow%2Fpcaps%2Fw2019-smb2-create-delay-getinfo-write-close.pcapng&data=02%7C01%7Cbburgin%40microsoft.com%7Cbf4aa31832ea4dc652e208d750c79be3%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637066690559680175&sdata=p%2BDwuhUCCb0qdaU4YCVeZ2DWRR1WxiRciuLiHOJsIlc%3D&reserved=0>

I'm trying to figure out what's changed wrt File.LastModificationTime between Windows 2003, from which Samba's behaviour was derived, and Window 2019 and so far all this doesn't make sense.

The scenario in this case is also dependent on the time between step A and B (none is this example above). It seems if the time between A and B is bigger then a certain threshold of ~15 ms, then the behaviour changes and we see an immediate update of the timestamp in step B (packet 80):

<https://nam06.safelinks.protection.outlook.com/?url=http:%2F%2Fwww.samba.org%2F~slow%2Fpcaps%2Fw2019-smb2-create-delay-15ms-getinfo-write-close.pcapng&data=02%7C01%7Cbburgin%40microsoft.com%7Cbf4aa31832ea4dc652e208d750c79be3%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637066690559690169&sdata=9sSLLfagPOBw6r4TryiEG0oYd3iwdOFQdiKEBcmAI8E%3D&reserved=0>

Cf case 119101121001349 for another related question.

Questions
=========

Is this behaviour documented somewhere? It would be good to get File.LastModificationTime (plus friends) behaviour documented across the full set of affecting operations.

I have further observations and traces from more complex scenarios, but I'm trying to come up with the most simple one and later expand on that. :)

Thanks!
-slow

-- 
Ralph Boehme, Samba Team                https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fsamba.org%2F&data=02%7C01%7Cbburgin%40microsoft.com%7Cbf4aa31832ea4dc652e208d750c79be3%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637066690559690169&sdata=VySaFmstJI5Z3Oyo1EIA6mBrOT6CtpAE7676p%2BkbYEM%3D&reserved=0
Samba Developer, SerNet GmbH   https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fsernet.de%2Fen%2Fsamba%2F&data=02%7C01%7Cbburgin%40microsoft.com%7Cbf4aa31832ea4dc652e208d750c79be3%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637066690559690169&sdata=Gl%2B88WqvSRnR9j87ijesAh2HEn9GIuFX3v8yg82f6ps%3D&reserved=0
GPG-Fingerprint   FAE2C6088A24252051C559E4AA1E9B7126399E46