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

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

Date: Fri, 1 Aug 2014 14:55:05 -0400



From: Austin Clements

I have a prototype implementation of message modification times on my
lastmod-v1 branch at

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


Quoth Gaute Hope on Jul 28 at  4:37 pm:
>    On Thu, Jul 3, 2014 at 12:42 PM, David Bremner <[1]>
>    wrote:
>      Gaute Hope <[2]> 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.
>      The discussion on this proposal seems to have died out without reaching
>      a conclusion. David M expressed a strong preference for some kind of
>      modification time field in the database.  Gaute agreed with some caveats
>      that such an approach could solve his problems as well. On the other
>      hand, nobody seems to be actually working on such an approach at the
>      moment.  Gaute and or David do you have any interest in revisiting the
>      series [3] and
>      seeing if it can be reworked into mergeable shape? I suspect in
>      particular something needs to be added with respect to message deletion
>      Thomas, are you still running some variant of these patches?
>      d
>    I am afraid I don't have the chance to put in any consistent effort on
>    this at the moment.
>    I agree, message deletion needs to be solved somehow.
>    Regards, Gaute