Fun with write time updates (bug #13541)

[Jeremy Allison]

On Fri, Aug 17, 2018 at 04:20:49PM +0200, Stefan Metzmacher via samba-technical wrote:
> Hi,
> 
> 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] 2.1.4.17 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
> https://download.microsoft.com/download/4/3/8/43889780-8d45-4b2e-9d3a-c696a890309f/File%20System%20Behavior%20Overview.pdf
> 
> LastWriteTime:
> - Set to the current time when the file is created during processing of
>   IRP_MJ_CREATE.
> - Set to the current time on a supersede/overwrite open, or on a stream
>   rename.
> - 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 !

Jeremy.