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

diff --git a/c7/8fc64abd567c69ca0fff1e6ce3031b01fcb89c b/c7/8fc64abd567c69ca0fff1e6ce3031b01fcb89c
new file mode 100644 (file)
index 0000000..e529019
--- /dev/null
+++ b/c7/8fc64abd567c69ca0fff1e6ce3031b01fcb89c
@@ -0,0 +1,93 @@
+Return-Path:\r
+ <return-z6xc2xnzh5j88kwfw4mkg79bw2@temporary-address.scs.stanford.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 53FF6431FBF\r
+       for <notmuch@notmuchmail.org>; Wed, 23 Apr 2014 02:00:20 -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 OI-Q3H0aTVKv for <notmuch@notmuchmail.org>;\r
+       Wed, 23 Apr 2014 02:00:15 -0700 (PDT)\r
+Received: from market.scs.stanford.edu (market.scs.stanford.edu [171.66.3.10])\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 B53CF431FBD\r
+       for <notmuch@notmuchmail.org>; Wed, 23 Apr 2014 02:00:15 -0700 (PDT)\r
+Received: from market.scs.stanford.edu (localhost.scs.stanford.edu\r
+ [127.0.0.1])  by market.scs.stanford.edu (8.14.7/8.14.7) with ESMTP id\r
+ s3N90B63021064;       Wed, 23 Apr 2014 02:00:11 -0700 (PDT)\r
+Received: (from dm@localhost)\r
+       by market.scs.stanford.edu (8.14.7/8.14.7/Submit) id s3N90BRf001972;\r
+       Wed, 23 Apr 2014 02:00:11 -0700 (PDT)\r
+X-Authentication-Warning: market.scs.stanford.edu: dm set sender to\r
+       return-z6xc2xnzh5j88kwfw4mkg79bw2@ta.scs.stanford.edu using -f\r
+From: David Mazieres <dm-list-email-notmuch@scs.stanford.edu>\r
+To: Gaute Hope <eg@gaute.vetsj.com>, David Bremner <david@tethera.net>,\r
+       notmuch <notmuch@notmuchmail.org>\r
+Subject: Re: [PATCH] Add configurable changed tag to messages that have been\r
+       changed on disk\r
+In-Reply-To: <1398237865-sup-624@qwerzila>\r
+References: <1396800683-9164-1-git-send-email-eg@gaute.vetsj.com>\r
+       <87wqf2gqig.fsf@ta.scs.stanford.edu> <1397140962-sup-6514@qwerzila>\r
+       <87wqexnqvb.fsf@ta.scs.stanford.edu> <1397163239-sup-5101@qwerzila>\r
+       <87d2g9ja0h.fsf@maritornes.cs.unb.ca> <1398237865-sup-624@qwerzila>\r
+Date: Wed, 23 Apr 2014 02:00:10 -0700\r
+Message-ID: <87ioq0l8th.fsf@ta.scs.stanford.edu>\r
+MIME-Version: 1.0\r
+Content-Type: text/plain\r
+X-BeenThere: notmuch@notmuchmail.org\r
+X-Mailman-Version: 2.1.13\r
+Precedence: list\r
+Reply-To: David Mazieres expires 2014-07-22 PDT\r
+       <mazieres-eqbxrjbqrn7vs5xdx45e9hkucs@temporary-address.scs.stanford.edu>\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: Wed, 23 Apr 2014 09:00:20 -0000\r
+\r
+Gaute Hope <eg@gaute.vetsj.com> writes:\r
+\r
+> A db-tick or a _good_ ctime solution can as far as I can see solve both\r
+> David M's (correct me if I am wrong) and my purposes, as well as\r
+> probably have more use cases in the future. It would even be an\r
+> interesting direct search: show me everything that changed lately,\r
+> sorted.\r
+\r
+I could live with a db-tick scheme.  I would prefer a ctime scheme,\r
+since then I can answer questions such as "what has changed in the last\r
+five minutes"?  I mean all kinds of other stuff starts to break if your\r
+clock goes backwards on a mail server machine, not the least of which is\r
+that incremental backups will fail silently, so you risk losing your\r
+mail.\r
+\r
+A middle ground might be to use the maximum of two values: 1) the\r
+time-of-day at which notmuch started executing, and 2) the highest ctime\r
+in the database plus 100 microseconds (leaving plenty of slop to store\r
+timestamps as IEEE doubles with 52 significant bits).  Since the values\r
+will be Btree-indexed, computing the max plus one will be cheap.\r
+\r
+Incidentally, if you are really this paranoid about time stamps, it\r
+should bother you that notmuch's directory timestamps only have one\r
+second granularity.  It's not that hard to get a new message delivered\r
+in the same second that notmuch new finished running.  In my\r
+synchronizer, I convert st_mtim (a struct timespec) into a double and\r
+keep that plus size in the database to decide if I need to re-hash\r
+files.  But for directories, I'm stuck with NOTMUCH_VALUE_TIMESTAMP,\r
+which are quantized to the second.  (Ironically, I think\r
+Xapian::sortable_serialize converts time_ts to doubles anyway, so\r
+avoiding st_mtim is not really helping performance.)\r
+\r
+David\r