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

Ralph Boehme slow at samba.org
Mon Oct 14 16:57:26 UTC 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


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

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://samba.org/
Samba Developer, SerNet GmbH   https://sernet.de/en/samba/
GPG-Fingerprint   FAE2C6088A24252051C559E4AA1E9B7126399E46

More information about the cifs-protocol mailing list