[cifs-protocol] MS-SMB2/FSA: File.LastModificationTime, update "lost" against Windows 2019
slow at samba.org
Mon Oct 14 16:57:26 UTC 2019
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
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).
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/
More information about the cifs-protocol