Fun with write time updates (bug #13541)

[Stefan Metzmacher]

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).

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?

Comments welcome:-)
metze


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://lists.samba.org/pipermail/samba-technical/attachments/20180817/a6d029ed/signature.sig>