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

[Gaute Hope]

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.

cheers, gaute