[PATCH] Add configurable changed tag to messages that have been changed on disk
Gaute Hope
eg at gaute.vetsj.com
Wed Apr 23 04:53:10 PDT 2014
Excerpts from David Mazieres's message of 2014-04-23 11:00:10 +0200:
> Gaute Hope <eg at gaute.vetsj.com> writes:
>
> > A db-tick or a _good_ ctime solution can as far as I can see solve both
> > David M's (correct me if I am wrong) and my purposes, as well as
> > probably have more use cases in the future. It would even be an
> > interesting direct search: show me everything that changed lately,
> > sorted.
>
> I could live with a db-tick scheme. I would prefer a ctime scheme,
> since then I can answer questions such as "what has changed in the last
> five minutes"? I mean all kinds of other stuff starts to break if your
> clock goes backwards on a mail server machine, not the least of which is
> that incremental backups will fail silently, so you risk losing your
> mail.
>
> A middle ground might be to use the maximum of two values: 1) the
> time-of-day at which notmuch started executing, and 2) the highest ctime
> in the database plus 100 microseconds (leaving plenty of slop to store
> timestamps as IEEE doubles with 52 significant bits). Since the values
> will be Btree-indexed, computing the max plus one will be cheap.
>
> Incidentally, if you are really this paranoid about time stamps, it
> should bother you that notmuch's directory timestamps only have one
> second granularity. It's not that hard to get a new message delivered
> in the same second that notmuch new finished running. In my
> synchronizer, I convert st_mtim (a struct timespec) into a double and
> keep that plus size in the database to decide if I need to re-hash
> files. But for directories, I'm stuck with NOTMUCH_VALUE_TIMESTAMP,
> which are quantized to the second. (Ironically, I think
> Xapian::sortable_serialize converts time_ts to doubles anyway, so
> avoiding st_mtim is not really helping performance.)
Agreed, it probably won't be the end of the world.. I will have to
handle conflicts anyway. With an inclusion of ctime my 'changed'-tag
patches are unnecessary.
By the way, muchsync looks very promising!
Cheers, gaute
More information about the notmuch
mailing list