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

[Gaute Hope]

Excerpts from Gaute Hope's message of August 6, 2014 10:29:
> Austin Clements <amdragon at MIT.EDU> wrote on Fri, 01 Aug 2014 14:55:05 -0400:
>> I have a prototype implementation of message modification times on my
>> lastmod-v1 branch at
>> 
>>   https://github.com/aclements/notmuch/tree/lastmod-v1
>> 
>> It builds on my database features series that's currently awaiting
>> review [1].
>> 
>> The series uses a monotonic revision number, rather than wall-clock
>> time, for reasons related to Xapian's concurrent control and detailed
>> in the main commit's commit message.  The implementation isn't quite
>> useful from the CLI yet because I haven't added any way to query the
>> database's current revision number.  (I'm still thinking about how I
>> want to do this, since search/show don't have a good way to deliver
>> "additional" information right now.  I might just add the last
>> modification for each individual message/max of all messages in a
>> thread, similar to what Thomas Jost's patch did long ago.)
>> 
>> [1] id:1406859003-11561-1-git-send-email-amdragon at mit.edu
 
> this should allow me to do what I wish to accomplish. The message
> deletion is still a problem though, I can see two options at the moment:

Hi list,

While exploring the possibility of syncing maildir/X-keywords with tags
I had some thoughts about lastmod and message modification:

As briefly discussed on #notmuch, I noticed that it seems that 'notmuch
new' does not detect that a message source has been changed, unless the
file is also re-named.

This means that for instance if the X-Keywords fields have been updated
in a message (from GMail with offlineimap, synclabels = yes) the lastmod
field will remain unchanged, and a source modification will be
undetectable to a client program using this value.

Would it not make sense that if a message has a more recent mtime than
at index time it is re-indexed?

Also, for the lastmod branch I would wish for a notmuch_message_touch()
method where the lastmod time is updated to the last. As well as a
notmuch_database_reindex_message () - possibly defined/documented
behaviour for notmuch_database_add_message () when the filename is
already added (in which case I would expect notmuch to re-index the
message).

Doing notmuch_database_remove_message followed by _add_message could
risk deleting the entry if this file is the only on-disk-representation.

Cheers, Gaute