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
