c7/8fc64abd567c69ca0fff1e6ce3031b01fcb89c

   1 Return-Path:\r
   2  <return-z6xc2xnzh5j88kwfw4mkg79bw2@temporary-address.scs.stanford.edu>\r
   3 X-Original-To: notmuch@notmuchmail.org\r
   4 Delivered-To: notmuch@notmuchmail.org\r
   5 Received: from localhost (localhost [127.0.0.1])\r
   6         by olra.theworths.org (Postfix) with ESMTP id 53FF6431FBF\r
   7         for <notmuch@notmuchmail.org>; Wed, 23 Apr 2014 02:00:20 -0700 (PDT)\r
   8 X-Virus-Scanned: Debian amavisd-new at olra.theworths.org\r
   9 X-Spam-Flag: NO\r
  10 X-Spam-Score: -2.3\r
  11 X-Spam-Level: \r
  12 X-Spam-Status: No, score=-2.3 tagged_above=-999 required=5\r
  13         tests=[RCVD_IN_DNSWL_MED=-2.3] autolearn=disabled\r
  14 Received: from olra.theworths.org ([127.0.0.1])\r
  15         by localhost (olra.theworths.org [127.0.0.1]) (amavisd-new, port 10024)\r
  16         with ESMTP id OI-Q3H0aTVKv for <notmuch@notmuchmail.org>;\r
  17         Wed, 23 Apr 2014 02:00:15 -0700 (PDT)\r
  18 Received: from market.scs.stanford.edu (market.scs.stanford.edu [171.66.3.10])\r
  19         (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))\r
  20         (No client certificate requested)\r
  21         by olra.theworths.org (Postfix) with ESMTPS id B53CF431FBD\r
  22         for <notmuch@notmuchmail.org>; Wed, 23 Apr 2014 02:00:15 -0700 (PDT)\r
  23 Received: from market.scs.stanford.edu (localhost.scs.stanford.edu\r
  24  [127.0.0.1])   by market.scs.stanford.edu (8.14.7/8.14.7) with ESMTP id\r
  25  s3N90B63021064;        Wed, 23 Apr 2014 02:00:11 -0700 (PDT)\r
  26 Received: (from dm@localhost)\r
  27         by market.scs.stanford.edu (8.14.7/8.14.7/Submit) id s3N90BRf001972;\r
  28         Wed, 23 Apr 2014 02:00:11 -0700 (PDT)\r
  29 X-Authentication-Warning: market.scs.stanford.edu: dm set sender to\r
  30         return-z6xc2xnzh5j88kwfw4mkg79bw2@ta.scs.stanford.edu using -f\r
  31 From: David Mazieres <dm-list-email-notmuch@scs.stanford.edu>\r
  32 To: Gaute Hope <eg@gaute.vetsj.com>, David Bremner <david@tethera.net>,\r
  33         notmuch <notmuch@notmuchmail.org>\r
  34 Subject: Re: [PATCH] Add configurable changed tag to messages that have been\r
  35         changed on disk\r
  36 In-Reply-To: <1398237865-sup-624@qwerzila>\r
  37 References: <1396800683-9164-1-git-send-email-eg@gaute.vetsj.com>\r
  38         <87wqf2gqig.fsf@ta.scs.stanford.edu> <1397140962-sup-6514@qwerzila>\r
  39         <87wqexnqvb.fsf@ta.scs.stanford.edu> <1397163239-sup-5101@qwerzila>\r
  40         <87d2g9ja0h.fsf@maritornes.cs.unb.ca> <1398237865-sup-624@qwerzila>\r
  41 Date: Wed, 23 Apr 2014 02:00:10 -0700\r
  42 Message-ID: <87ioq0l8th.fsf@ta.scs.stanford.edu>\r
  43 MIME-Version: 1.0\r
  44 Content-Type: text/plain\r
  45 X-BeenThere: notmuch@notmuchmail.org\r
  46 X-Mailman-Version: 2.1.13\r
  47 Precedence: list\r
  48 Reply-To: David Mazieres expires 2014-07-22 PDT\r
  49         <mazieres-eqbxrjbqrn7vs5xdx45e9hkucs@temporary-address.scs.stanford.edu>\r
  50 List-Id: "Use and development of the notmuch mail system."\r
  51         <notmuch.notmuchmail.org>\r
  52 List-Unsubscribe: <http://notmuchmail.org/mailman/options/notmuch>,\r
  53         <mailto:notmuch-request@notmuchmail.org?subject=unsubscribe>\r
  54 List-Archive: <http://notmuchmail.org/pipermail/notmuch>\r
  55 List-Post: <mailto:notmuch@notmuchmail.org>\r
  56 List-Help: <mailto:notmuch-request@notmuchmail.org?subject=help>\r
  57 List-Subscribe: <http://notmuchmail.org/mailman/listinfo/notmuch>,\r
  58         <mailto:notmuch-request@notmuchmail.org?subject=subscribe>\r
  59 X-List-Received-Date: Wed, 23 Apr 2014 09:00:20 -0000\r
  60 \r
  61 Gaute Hope <eg@gaute.vetsj.com> writes:\r
  62 \r
  63 > A db-tick or a _good_ ctime solution can as far as I can see solve both\r
  64 > David M's (correct me if I am wrong) and my purposes, as well as\r
  65 > probably have more use cases in the future. It would even be an\r
  66 > interesting direct search: show me everything that changed lately,\r
  67 > sorted.\r
  68 \r
  69 I could live with a db-tick scheme.  I would prefer a ctime scheme,\r
  70 since then I can answer questions such as "what has changed in the last\r
  71 five minutes"?  I mean all kinds of other stuff starts to break if your\r
  72 clock goes backwards on a mail server machine, not the least of which is\r
  73 that incremental backups will fail silently, so you risk losing your\r
  74 mail.\r
  75 \r
  76 A middle ground might be to use the maximum of two values: 1) the\r
  77 time-of-day at which notmuch started executing, and 2) the highest ctime\r
  78 in the database plus 100 microseconds (leaving plenty of slop to store\r
  79 timestamps as IEEE doubles with 52 significant bits).  Since the values\r
  80 will be Btree-indexed, computing the max plus one will be cheap.\r
  81 \r
  82 Incidentally, if you are really this paranoid about time stamps, it\r
  83 should bother you that notmuch's directory timestamps only have one\r
  84 second granularity.  It's not that hard to get a new message delivered\r
  85 in the same second that notmuch new finished running.  In my\r
  86 synchronizer, I convert st_mtim (a struct timespec) into a double and\r
  87 keep that plus size in the database to decide if I need to re-hash\r
  88 files.  But for directories, I'm stuck with NOTMUCH_VALUE_TIMESTAMP,\r
  89 which are quantized to the second.  (Ironically, I think\r
  90 Xapian::sortable_serialize converts time_ts to doubles anyway, so\r
  91 avoiding st_mtim is not really helping performance.)\r
  92 \r
  93 David\r