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

Jeff McCashland jeffm at microsoft.com
Mon Oct 14 18:04:33 UTC 2019

[Bryan to BCC]

Hi Ralph,

I will research your question, and also touch bases with Sreekanth regarding related SR 119101121001349.

I will let you know what I find. 

Best regards,
Jeff McCashland | Senior Escalation Engineer | Microsoft Protocol Open Specifications Team 
Phone: +1 (425) 703-8300 x38300 | Hours: 9am-5pm | Time zone: (UTC-08:00) Pacific Time (US and Canada)
Local country phone number found here: http://support.microsoft.com/globalenglish | Extension 1138300
We value your feedback.  My manager is Jeremy Chapman (jeremyc), +1 (469) 775-2475

-----Original Message-----
From: Bryan Burgin <bburgin at microsoft.com> 
Sent: Monday, October 14, 2019 10:09 AM
To: Ralph Boehme <slow at samba.org>
Cc: cifs-protocol at lists.samba.org; support <support at mail.support.microsoft.com>
Subject: [REG:119101421001093] MS-SMB2/FSA: File.LastModificationTime, update "lost" against Windows 2019

[-Dochelp to bcc]

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.


-----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.


A) SMB client creates testfile -> handle H1

B) Client queries LastModificationTime with SMB2 GETINFO

C) Client writes to handle H1

D) 1 s delay


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


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


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.


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):


Cf case 119101121001349 for another related question.


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. :)


Ralph Boehme, Samba Team                https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fsamba.org%2F&data=02%7C01%7Cjeffm%40microsoft.com%7Cdc162dff44784fd4b49508d750c93e57%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637066697576594771&sdata=knm7ouiTpjnn9T6HvK0A%2FPe%2Bl7bUetCvHWLIS6Wqnos%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%7Cjeffm%40microsoft.com%7Cdc162dff44784fd4b49508d750c93e57%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637066697576594771&sdata=L2seP74i%2BwMyVDxOLfFvyBH6wHQTH19XfmehzbqSAxk%3D&reserved=0
GPG-Fingerprint   FAE2C6088A24252051C559E4AA1E9B7126399E46

More information about the cifs-protocol mailing list