Given the following sequence of SMB2 operations:

A) create

B) write

...wait 3 seconds...

C) getinfo SMB2_FILE_ALL_INFO

D) write

...wait 1 second...

E) close with SMB2_CLOSE_FLAGS_FULL_INFORMATION

On a Windows server the file's write-time is updated

1. 2 seconds after B)

On a Samba server the file's write-time is updated

1. 2 seconds after B)

2. at stage E) when the handle is closed

This is wrong: there's no delayed write-time update pending, so the close shouldn't update the write-time.

In our code the problem is caused by fsp->update_write_time_on_close never being reset. Setting this to false in fsp_flush_write_time_update() might do the trick, but this needs a closer look.

This particular sequence of operations is suprisingly not tested, so we got it wrong.

Working on fix, need bugnumber...