Write times fix for S3

[Jeremy Allison]

On Fri, Sep 05, 2008 at 07:00:36PM -0700, Jeremy Allison wrote:
> Ok, here's the fix for the write times breakage
> with the new tests in S4 smbtorture.
> 
> The key is keeping in the share mode struct
> the "old_file_time" as the real write time,
> set by all the write and allocation calls,
> and the "changed_write_time" as the "sticky"
> write time - set by the SET_FILE_TIME calls.
> 
> We can set them independently (although I
> kept the optimization of not setting the
> "old_file_time" is a "changed_write_time"
> was already set, as we'll never see it.
> 
> This allows us to update the write time
> immediately on the SMBwrite truncate case,
> SET_END_OF_FILE and SET_ALLOCATION_SIZE calls,
> whilst still have the 2 second delay on the
> "normal" SMBwrite, SMBwriteX calls.
> 
> I think in a subsequent patch I'd like to
> change the name of these from "old_file_time"
> to "write_time" and "changed_write_time" to
> "sticky_write_time" to make this clearer.
> 
> I think I also fixed a bug in Metze's original
> code in that once a write timestamp had been
> set from a "normal" SMBwriteX call the fsp->update_write_time_triggered
> variable was set and then never reset - thus
> meaning the write timestamp would never get
> updated again on subsequent SMBwriteX's.
> 
> The new code checks the update_write_time_event
> event instead, and doesn't update is there's
> an event already scheduled.
> 
> Metze especially, please check this over for
> your understanding.

I'm going to add more tests on Monday to flesh
out this (presumed) data model for how write
times are done. Most importantly, if I'm correct
then after a SET_WRITE_TIME call is done on
one handle, then after that handle is closed
subsequant writes should start to update again.
I don't think our current code does that (as
we'd need to null out the "changed_write_time" field
in the share mode struct on close and we don't
currently do that.

Jeremy.