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

[Tomi Ollila]

On Mon, Sep 22 2014, Gaute Hope <eg at gaute.vetsj.com> wrote:

> 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?

That would require notmuch to scan the contents of a directory for changed
mtimes of the files -- now notmuch skips looking for the files unless
directory mtime has changed. Directory mtime changes when files are
added/deleted/renamed (as that is what directory needs to know) -- file
mtime change are stored in file information and therefore change there does
not probagate to parent directory (and, if such happened, to it's parent
and so on...)

That would mean the scanning would be slower than it is now.

Tomi

>
> 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