[cifs-protocol] [MS-FSA] Setting end-of-file on file-handle with pending delayed write-time update
slow at samba.org
Wed Dec 11 06:49:45 UTC 2019
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.
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
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
* flush happens even if the requested size equals the existing size
If this is correct, are there other operations that trigger this behaviour?
For completenes, here's also a pcap against Windows 2019:
This one stops at step 4 when the client test driver detects that
write-time did already change.
Ralph Boehme, Samba Team https://samba.org/
Samba Developer, SerNet GmbH https://sernet.de/en/samba/
More information about the cifs-protocol