[PATCH] Add configurable changed tag to messages that have been changed on disk

[Gaute Hope]

Excerpts from David Mazieres's message of 2014-04-06 22:19:19 +0200:
> Gaute Hope <eg at gaute.vetsj.com> writes:
>
> > When one of the source files for a message is changed on disk, renamed,
> > deleted or a new source file is added. A configurable changed tag is
> > is added. The tag can be configured under the option 'changed_tags' in
> > the [new] section, the default is none. Tests have been updated to
> > accept the new config option.
> >
> > notmuch-setup now asks for a changed tag after the new tags question.
> >
> > This could be useful for for example 'afew' to detect remote changes in
> > IMAP folders and update the FolderNameFilter to also add tags or remove
> > tags when a _existing_ message has been added to or removed from a
> > maildir.
>
> I think this is the wrong way to achieve such functionality, because
> then the change tag A) is expensive to remove, B) is easy to misuse
> (remember to call fsync everywhere before deleting the change tag), and
> C) can be used by only one application.
>
> A better approach would be to add a new "modtime" xapian value that is
> updated whenever the tags or any other terms (such as XFDIRENTRY) are
> added to or deleted from a docid.  If it's a Xapian value, rather than a
> term, then modtime will be queriable just like date, allowing multiple
> applications to query all docids modified since the last time they ran.
>
> [... snip]

This could also solve it, and probably have more uses. I don't quite see
how the opposite problem (for my use case) can be solved by this without
using a 'localchange' tag. This is to sync tag to maildir sync, when a
new tag has been added (by e.g. a user interaction in a client) it needs
to be copied to the maildir, if it is not done in the same go a
different application won't know whether the change was local or remote.
How did you solve this?

I would suggest using a Xapian- or Index-time which gets a tick
everytime a modification is made to the index. Atomic operations could
operate on the same time in case this distinction turns out to be
useful. Perhaps something like this already exists in Xapian? This way
clock skew, clock resolution (lots of operations happening in the same
second, msec or nanosec) problems won't be an issue. The crux will be to
make sure all write-operations trigger a tick on the indextime.

Regards, Gaute