Write times code update.
authorJeremy Allison <jra@samba.org>
Sat, 6 Sep 2008 02:00:48 +0000 (19:00 -0700)
committerJeremy Allison <jra@samba.org>
Sat, 6 Sep 2008 02:00:48 +0000 (19:00 -0700)
commit405b072431db3f3f8f16e4e0d2f2b1b2f1c71286
tree8a44daaa1bb7912a33ecb1145f48ef4f13e2fe32
parenta90ba70cbf8af0d6081f6bb02cae71b955126c49
Write times code update.

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.

Jeremy.
(This used to be commit 6f20585419046c4aca1f7d6c863cf79eb6ae53b0)
source3/include/proto.h
source3/include/smb.h
source3/locking/locking.c
source3/smbd/dosmode.c
source3/smbd/fileio.c
source3/smbd/reply.c
source3/smbd/trans2.c