Hello dochelp! Note: the following only applies to Windows versions where the SMB server implements delayed write-time updates. I've verified that the behaviour described below is reproducible against the following Windows versions: Windows 7, Windows 2008r2 and Windows 2016.
With Windows 2019 I see a different behaviour, which is as expected, as it implements immediate timestamp updates. SMB2 scenario: 1) create file -> file handle H1 2) sleep one second 3) write one byte to H1 4) getinfo on H1 -> write-time hasn't been updated, delayed update still pending 5) setinfo end-of-file with size=1 on H1 (so existing size = requested new size) 6) getinfo again on H1 -> now the write-time has been updated This is the behaviour that is reproducible against Windows 7, Windows 2008r2, Windows 2016, but not Windows 2019. Apparently, the setinfo in step 5 flushed the pending write-time update. Question: as the legacy delayed write-time handling is not (was never?) documented in MS-FSA, I'm asking for confirmation that the following conclusion is correct: * a setinfo-eof on a file-handle flushes pending write-time updates * flush happens even if the requested size equals the existing size If this is correct, are there other operations that trigger this behaviour? pcap: <http://www.samba.org/~slow/pcaps/bug14150.pcapng.gz> For completenes, here's also a pcap against Windows 2019: <http://www.samba.org/~slow/pcaps/bug14150-w2019.pcapng.gz> This one stops at step 4 when the client test driver detects that write-time did already change. Thanks! -slow -- Ralph Boehme, Samba Team https://samba.org/ Samba Developer, SerNet GmbH https://sernet.de/en/samba/ GPG-Fingerprint FAE2C6088A24252051C559E4AA1E9B7126399E46 _______________________________________________ cifs-protocol mailing list [email protected] https://lists.samba.org/mailman/listinfo/cifs-protocol
