Excerpts from Gaute Hope's message of August 6, 2014 10:29: > Austin Clements <amdragon@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@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