--- /dev/null
+Return-Path: <amdragon@mit.edu>\r
+X-Original-To: notmuch@notmuchmail.org\r
+Delivered-To: notmuch@notmuchmail.org\r
+Received: from localhost (localhost [127.0.0.1])\r
+ by olra.theworths.org (Postfix) with ESMTP id E8D37431FC4\r
+ for <notmuch@notmuchmail.org>; Mon, 22 Sep 2014 08:40:40 -0700 (PDT)\r
+X-Virus-Scanned: Debian amavisd-new at olra.theworths.org\r
+X-Spam-Flag: NO\r
+X-Spam-Score: -2.3\r
+X-Spam-Level: \r
+X-Spam-Status: No, score=-2.3 tagged_above=-999 required=5\r
+ tests=[RCVD_IN_DNSWL_MED=-2.3] autolearn=disabled\r
+Received: from olra.theworths.org ([127.0.0.1])\r
+ by localhost (olra.theworths.org [127.0.0.1]) (amavisd-new, port 10024)\r
+ with ESMTP id AcXiMF6aUGtd for <notmuch@notmuchmail.org>;\r
+ Mon, 22 Sep 2014 08:40:34 -0700 (PDT)\r
+Received: from dmz-mailsec-scanner-4.mit.edu (dmz-mailsec-scanner-4.mit.edu\r
+ [18.9.25.15])\r
+ (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))\r
+ (No client certificate requested)\r
+ by olra.theworths.org (Postfix) with ESMTPS id D7C12431FB6\r
+ for <notmuch@notmuchmail.org>; Mon, 22 Sep 2014 08:40:33 -0700 (PDT)\r
+X-AuditID: 1209190f-f79aa6d000005b45-cc-542042f1fcc5\r
+Received: from mailhub-auth-2.mit.edu ( [18.7.62.36])\r
+ (using TLS with cipher AES256-SHA (256/256 bits))\r
+ (Client did not present a certificate)\r
+ by dmz-mailsec-scanner-4.mit.edu (Symantec Messaging Gateway) with SMTP\r
+ id 42.96.23365.1F240245; Mon, 22 Sep 2014 11:40:33 -0400 (EDT)\r
+Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11])\r
+ by mailhub-auth-2.mit.edu (8.13.8/8.9.2) with ESMTP id s8MFeWQn028356; \r
+ Mon, 22 Sep 2014 11:40:32 -0400\r
+Received: from drake.dyndns.org\r
+ (HSI-KBW-109-192-025-091.hsi6.kabel-badenwuerttemberg.de\r
+ [109.192.25.91]) (authenticated bits=0)\r
+ (User authenticated as amdragon@ATHENA.MIT.EDU)\r
+ by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id s8MFeDNc030355\r
+ (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT);\r
+ Mon, 22 Sep 2014 11:40:29 -0400\r
+Received: from amthrax by drake.dyndns.org with local (Exim 4.84)\r
+ (envelope-from <amdragon@mit.edu>)\r
+ id 1XW5ik-0005OB-KO; Mon, 22 Sep 2014 11:40:10 -0400\r
+From: Austin Clements <aclements@csail.mit.edu>\r
+To: Gaute Hope <eg@gaute.vetsj.com>, notmuch@notmuchmail.org\r
+Subject: Re: [PATCH] Add configurable changed tag to messages that have\r
+ been changed on disk\r
+In-Reply-To: <1411386960-astroid-2-k1e726ut3f-2518@strange>\r
+References: <1396800683-9164-1-git-send-email-eg@gaute.vetsj.com>\r
+ <87fviiiuzn.fsf@maritornes.cs.unb.ca>\r
+ <CABKe4Mv6p77i5dBT9BV41hxmtrE4UPLR3NjZfpLuZDoE1KWYyA@mail.gmail.com>\r
+ <20140801185505.GS13893@mit.edu>\r
+ <1407313144-astroid-0-vyhth1tcrd-3835@strange>\r
+ <1411386960-astroid-2-k1e726ut3f-2518@strange>\r
+User-Agent: Notmuch/0.18.1+86~gef5e66a (http://notmuchmail.org) Emacs/24.3.1\r
+ (x86_64-pc-linux-gnu)\r
+Date: Mon, 22 Sep 2014 11:40:09 -0400\r
+Message-ID: <87k34vackm.fsf@drake.dyndns.org>\r
+MIME-Version: 1.0\r
+Content-Type: text/plain\r
+X-Brightmail-Tracker:\r
+ H4sIAAAAAAAAA+NgFnrPIsWRmVeSWpSXmKPExsUixG6novvRSSHEYOFCLoumz5dYLa7fnMns\r
+ wOTx418zm8ezVbeYA5iiuGxSUnMyy1KL9O0SuDI+f+xmKtgvW/G9t5exgfGfeBcjJ4eEgInE\r
+ ih3HmSBsMYkL99azdTFycQgJzGaS+PjtPCOEs5FR4uDpDVCZ+0wSk7ouskM4cxklJqycxw7S\r
+ zyagL7Fi7SRWEFtEwEbi1Pr9YLawQIzEvQOvGEFsTgFriXs3HjJDNK9mkjj6eDNYQlQgSWLx\r
+ ojnMIDaLgKrEhxPLweK8AroSXdcOMEPYghInZz5hAbGZBSQkDr54wTyBUWAWktQsJKkFjEyr\r
+ GGVTcqt0cxMzc4pTk3WLkxPz8lKLdE30cjNL9FJTSjcxgsKSU5J/B+O3g0qHGAU4GJV4eBc0\r
+ yYcIsSaWFVfmHmKU5GBSEuW9b6oQIsSXlJ9SmZFYnBFfVJqTWnyIUYKDWUmEN0gaKMebklhZ\r
+ lVqUD5OS5mBREufd9IMvREggPbEkNTs1tSC1CCYrw8GhJMFrCYw/IcGi1PTUirTMnBKENBMH\r
+ J8hwHqDhXiA1vMUFibnFmekQ+VOMuhzrOr/1Mwmx5OXnpUqJ8yqBFAmAFGWU5sHNgaWTV4zi\r
+ QG8J8xqBVPEAUxHcpFdAS5iAltw/Lg+ypCQRISXVwDi/OfsG46ufgpMTt3jIWOYfm1rD8DDu\r
+ aHT3iy9ed29fMOitVemokf2W0FN626ktM996i9LzD/nuux/wf5m3+Mn+tV9XJlXP6juSELVW\r
+ n1/nzf3W8Puxb63u8Lasv2VnYFaj0KAu85pZ8/jPm2x6wTOvrfVqOSJlq3pM7rP92sCjrhw3\r
+ +ebfaldiKc5INNRiLipOBABOaxnpAgMAAA==\r
+X-BeenThere: notmuch@notmuchmail.org\r
+X-Mailman-Version: 2.1.13\r
+Precedence: list\r
+List-Id: "Use and development of the notmuch mail system."\r
+ <notmuch.notmuchmail.org>\r
+List-Unsubscribe: <http://notmuchmail.org/mailman/options/notmuch>,\r
+ <mailto:notmuch-request@notmuchmail.org?subject=unsubscribe>\r
+List-Archive: <http://notmuchmail.org/pipermail/notmuch>\r
+List-Post: <mailto:notmuch@notmuchmail.org>\r
+List-Help: <mailto:notmuch-request@notmuchmail.org?subject=help>\r
+List-Subscribe: <http://notmuchmail.org/mailman/listinfo/notmuch>,\r
+ <mailto:notmuch-request@notmuchmail.org?subject=subscribe>\r
+X-List-Received-Date: Mon, 22 Sep 2014 15:40:41 -0000\r
+\r
+On Mon, 22 Sep 2014, Gaute Hope <eg@gaute.vetsj.com> wrote:\r
+> Excerpts from Gaute Hope's message of August 6, 2014 10:29:\r
+>> Austin Clements <amdragon@MIT.EDU> wrote on Fri, 01 Aug 2014 14:55:05 -0400:\r
+>>> I have a prototype implementation of message modification times on my\r
+>>> lastmod-v1 branch at\r
+>>> \r
+>>> https://github.com/aclements/notmuch/tree/lastmod-v1\r
+>>> \r
+>>> It builds on my database features series that's currently awaiting\r
+>>> review [1].\r
+>>> \r
+>>> The series uses a monotonic revision number, rather than wall-clock\r
+>>> time, for reasons related to Xapian's concurrent control and detailed\r
+>>> in the main commit's commit message. The implementation isn't quite\r
+>>> useful from the CLI yet because I haven't added any way to query the\r
+>>> database's current revision number. (I'm still thinking about how I\r
+>>> want to do this, since search/show don't have a good way to deliver\r
+>>> "additional" information right now. I might just add the last\r
+>>> modification for each individual message/max of all messages in a\r
+>>> thread, similar to what Thomas Jost's patch did long ago.)\r
+>>> \r
+>>> [1] id:1406859003-11561-1-git-send-email-amdragon@mit.edu\r
+> \r
+>> this should allow me to do what I wish to accomplish. The message\r
+>> deletion is still a problem though, I can see two options at the moment:\r
+>\r
+> Hi list,\r
+>\r
+> While exploring the possibility of syncing maildir/X-keywords with tags\r
+> I had some thoughts about lastmod and message modification:\r
+>\r
+> As briefly discussed on #notmuch, I noticed that it seems that 'notmuch\r
+> new' does not detect that a message source has been changed, unless the\r
+> file is also re-named.\r
+>\r
+> This means that for instance if the X-Keywords fields have been updated\r
+> in a message (from GMail with offlineimap, synclabels = yes) the lastmod\r
+> field will remain unchanged, and a source modification will be\r
+> undetectable to a client program using this value.\r
+>\r
+> Would it not make sense that if a message has a more recent mtime than\r
+> at index time it is re-indexed?\r
+\r
+This has the potential to make notmuch new substantially more expensive.\r
+Currently, if there are no changes, it only has to stat each directory\r
+in your maildir (in fact, some restructuring of new would let us\r
+eliminate almost all database access during a no-op notmuch new as\r
+well). Checking for changes to individual messages would require\r
+stat'ing every single message file as well as accessing the database to\r
+check the paths and mtimes of every message, increasing the number of\r
+stat calls and disk accesses by several orders of magnitude.\r
+\r
+It may be that this is fast enough that it's okay, but it would be good\r
+to gather some evidence first. That includes hot and cold caches, and\r
+maildir over NFS.\r
+\r
+With respect to X-Keywords specifically, note that it's a fairly basic\r
+design decision that notmuch never modifies message files. This gives\r
+us strong robustness guarantees we would be loathe to part with.\r
+\r
+It has puzzled me ever since offlineimap added X-Keywords why they\r
+didn't just translate these keywords into folders and create hard links\r
+of message files. Anything could interact smoothly with that.\r
+\r
+> Also, for the lastmod branch I would wish for a notmuch_message_touch()\r
+> method where the lastmod time is updated to the last. As well as a\r
+> notmuch_database_reindex_message () - possibly defined/documented\r
+> behaviour for notmuch_database_add_message () when the filename is\r
+> already added (in which case I would expect notmuch to re-index the\r
+> message).\r
+\r
+What's the use case for these?\r
+\r
+> Doing notmuch_database_remove_message followed by _add_message could\r
+> risk deleting the entry if this file is the only on-disk-representation.\r
+>\r
+> Cheers, Gaute\r
projects / notmuch-archives.git / commitdiff