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

[Austin Clements]

Quoth Gaute Hope on Aug 06 at 11:02 am:
> On Fri, Aug 1, 2014 at 8:55 PM, Austin Clements <amdragon at mit.edu> wrote:
> > 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
> 
> 
> Hi,
> 
> 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:
> 
> a)  output during notmuch new to a hook or a list somewhere deleted files.
>    if list: notmuch will not handle this list, only append to it and
> the user must
>    purge it when it is safe to do so.
> 
>    if hook: for my purposes I would just create a hook appending to the
>    list. as a minimum I think thread_id, message_id and revision number
>    should be included.
> 
> 
> b)  maintain a full list of deleted / dead messages. a user initiated
>    purge can clean this from the database. a tag could be used for this,
>    so that clients can ignore unlinked/deleted/dead messages. this
>    differs from a 'deleted' message (IMAP/Maildir context) that has not
>    yet been expunged so there is confusion to be avoided.
> 
>    a garbage collection function and interface must also be set up, but
>    this one is probably simple.
> 
> 
> in most cases I think a) would be sufficient, and probably much easier
> to do. it might be slow in cases where large amounts of messages have been
> deleted, but this is seldom the case for me at least.

I have a separate branch (also sitting on top of the features branch)
that implements "ghost" messages.  The main intent is to fix a bug we
currently have in threading, but it puts us in a good position to
maintain state for messages we don't have the content of, including
last modification times for deleted messages and pre-seeded tags for
undelivered messages (useful for pre-tagging sent messages as sent,
nmbug, notmuch insert, etc.)