Fun with write time updates (bug #13541)
jra at samba.org
Fri Aug 17 16:15:44 UTC 2018
On Fri, Aug 17, 2018 at 04:20:49PM +0200, Stefan Metzmacher via samba-technical wrote:
> I while debugging problems with a seamless durable reconnect from a
> Windows 10 client, I started to write SMB2 tests to explore the Windows
> behavior regarding delayed write time updates during a durable reconnect.
> It turns out that our write time update handling differs compared to
> recent Windows releases.
> We basically implement the behavior of Windows 2000:
> - The only write time update happens ~2 seconds after
> the first write.
> - If the handle was written the close will trigger
> a 2nd write time update.
> Both updates use the current timestamp.
> Windows >= 2008R2 behaves differently:
> (Actually I don't know when the behavior changed,
> I guess with 2008, as SMB2 was introduced):
> Behavior without SMB1 Query Path Info:
> - Write time updates are deferred up to 4 seconds
> after a write. Once the time is updated, the timer
> will be re-scheduled by the next write.
> - Close only updates the write time if a pending
> update is still pending.
> All updates use the current timestamp.
> Additional behavior with SMB1 Query Path Info:
> - If an SMB1 Query Path Info is processed
> Any pending timer on all open handles
> are removed. And no new timers are every scheduled
> on these handles.
> - The only write time update will happen on close (to the current time).
Great debugging Metze !
Our behavior here was a heuristic designed by me (I think)
to try and match what I saw from Windows at the time.
If you've figured out how it's supposed to work, that
would be a great improvement !
The SMB1 Query Path Info is a pathname-based query yeah ?
Could this be explained by an internal NtCreate call on
the pathname (don't have time to look that carefully
right now) ?
> I think we better implement the new behavior, as this is what all
> Windows SMB2 enabled servers provide, even over SMB1.
> First I was confused by the difference between the protocol,
> but once I removed the SMB1 query path info calls from
> the tests, SMB1 and SMB2 behaved in the same way for pure
> handle based access.
> The documentation doesn't include any delayed updates at all.
> [MS-FSA] 18.104.22.168 Algorithm for Noting That a File Has Been Modified
> The inputs for this algorithm are as follows:
> Open: The Open through which the file was modified.
> The pseudocode for the algorithm is as follows:
> If Open.UserSetModificationTime is FALSE, set
> Open.File.LastModificationTime to the current system time.
> If Open.UserSetChangeTime is FALSE, set Open.File.LastChangeTime to
> the current system time.
> If Open.UserSetAccessTime is FALSE, set Open.File.LastAccessTime to
> the current system time.
> Set Open.File.FileAttributes.FILE_ATTRIBUTE_ARCHIVE to TRUE.
> There're some more information in
> - Set to the current time when the file is created during processing of
> - Set to the current time on a supersede/overwrite open, or on a stream
> - Set when IRP_MJ_SET_INFORMATION is processed for the following
> information classes:
> - FileAllocationInformation
> - FileBasicInformation
> - FileEndOfFileInformation
> - Set when IRP_MJ_FLUSH_BUFFERS is processed.
> - Noted when a write is made to the file, set to the current time when
> the file
> handle is closed.
> Maybe the IRP_MJ_FLUSH_BUFFERS is the timer that updates the timestamp
> every few seconds.
> See https://bugzilla.samba.org/show_bug.cgi?id=13541
> I guess we want to to implement the behavior of modern Windows releases,
> any objections?
Sounds good to me !
More information about the samba-technical