c8/507e3a06186b9a997e46c067a6560316fa1c6e

   1 Return-Path: <amdragon@mit.edu>\r
   2 X-Original-To: notmuch@notmuchmail.org\r
   3 Delivered-To: notmuch@notmuchmail.org\r
   4 Received: from localhost (localhost [127.0.0.1])\r
   5         by olra.theworths.org (Postfix) with ESMTP id 24F29431FD0\r
   6         for <notmuch@notmuchmail.org>; Wed, 26 Jan 2011 07:07:37 -0800 (PST)\r
   7 X-Virus-Scanned: Debian amavisd-new at olra.theworths.org\r
   8 X-Spam-Flag: NO\r
   9 X-Spam-Score: 0\r
  10 X-Spam-Level: \r
  11 X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[none]\r
  12         autolearn=disabled\r
  13 Received: from olra.theworths.org ([127.0.0.1])\r
  14         by localhost (olra.theworths.org [127.0.0.1]) (amavisd-new, port 10024)\r
  15         with ESMTP id Zb44c7D8q00c for <notmuch@notmuchmail.org>;\r
  16         Wed, 26 Jan 2011 07:07:36 -0800 (PST)\r
  17 Received: from dmz-mailsec-scanner-3.mit.edu (DMZ-MAILSEC-SCANNER-3.MIT.EDU\r
  18         [18.9.25.14])\r
  19         by olra.theworths.org (Postfix) with ESMTP id 9CA9D431FB6\r
  20         for <notmuch@notmuchmail.org>; Wed, 26 Jan 2011 07:07:36 -0800 (PST)\r
  21 X-AuditID: 1209190e-b7b3bae000000a71-5d-4d4038b7166c\r
  22 Received: from mailhub-auth-3.mit.edu ( [18.9.21.43])\r
  23         by dmz-mailsec-scanner-3.mit.edu (Symantec Brightmail Gateway) with\r
  24         SMTP id 38.86.02673.7B8304D4; Wed, 26 Jan 2011 10:07:35 -0500 (EST)\r
  25 Received: from outgoing.mit.edu (OUTGOING-AUTH.MIT.EDU [18.7.22.103])\r
  26         by mailhub-auth-3.mit.edu (8.13.8/8.9.2) with ESMTP id p0QF7XqV029337; \r
  27         Wed, 26 Jan 2011 10:07:34 -0500\r
  28 Received: from awakening.csail.mit.edu (awakening.csail.mit.edu [18.26.4.91])\r
  29         (authenticated bits=0)\r
  30         (User authenticated as amdragon@ATHENA.MIT.EDU)\r
  31         by outgoing.mit.edu (8.13.6/8.12.4) with ESMTP id p0QF7Sm5012536\r
  32         (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT);\r
  33         Wed, 26 Jan 2011 10:07:29 -0500 (EST)\r
  34 Received: from amthrax by awakening.csail.mit.edu with local (Exim 4.72)\r
  35         (envelope-from <amdragon@mit.edu>)\r
  36         id 1Pi6y0-000840-Cg; Wed, 26 Jan 2011 10:07:28 -0500\r
  37 Date: Wed, 26 Jan 2011 10:07:28 -0500\r
  38 From: Austin Clements <amdragon@MIT.EDU>\r
  39 To: Carl Worth <cworth@cworth.org>\r
  40 Subject: Re: [PATCH 1/3] new: Do not defer maildir flag synchronization\r
  41         during the first run\r
  42 Message-ID: <20110126150728.GT13226@mit.edu>\r
  43 References: <1295603977-14326-1-git-send-email-sojkam1@fel.cvut.cz>\r
  44         <1295603977-14326-3-git-send-email-sojkam1@fel.cvut.cz>\r
  45         <AANLkTinsC+89yx7jGUaB8PLiftLjyTr7gosUDgAC_g0S@mail.gmail.com>\r
  46         <87pqrk10wm.fsf@yoom.home.cworth.org>\r
  47         <87mxmn27w6.fsf@yoom.home.cworth.org>\r
  48 MIME-Version: 1.0\r
  49 Content-Type: text/plain; charset=us-ascii\r
  50 Content-Disposition: inline\r
  51 In-Reply-To: <87mxmn27w6.fsf@yoom.home.cworth.org>\r
  52 User-Agent: Mutt/1.5.20 (2009-06-14)\r
  53 X-Brightmail-Tracker: AAAAAA==\r
  54 Cc: notmuch@notmuchmail.org\r
  55 X-BeenThere: notmuch@notmuchmail.org\r
  56 X-Mailman-Version: 2.1.13\r
  57 Precedence: list\r
  58 List-Id: "Use and development of the notmuch mail system."\r
  59         <notmuch.notmuchmail.org>\r
  60 List-Unsubscribe: <http://notmuchmail.org/mailman/options/notmuch>,\r
  61         <mailto:notmuch-request@notmuchmail.org?subject=unsubscribe>\r
  62 List-Archive: <http://notmuchmail.org/pipermail/notmuch>\r
  63 List-Post: <mailto:notmuch@notmuchmail.org>\r
  64 List-Help: <mailto:notmuch-request@notmuchmail.org?subject=help>\r
  65 List-Subscribe: <http://notmuchmail.org/mailman/listinfo/notmuch>,\r
  66         <mailto:notmuch-request@notmuchmail.org?subject=subscribe>\r
  67 X-List-Received-Date: Wed, 26 Jan 2011 15:07:37 -0000\r
  68 \r
  69 Quoth Carl Worth on Jan 26 at  9:59 pm:\r
  70 > On Wed, 26 Jan 2011 19:15:21 +1000, Carl Worth <cworth@cworth.org> wrote:\r
  71 > > But then I'm also wondering if perhaps we could do the processing undeferred\r
  72 > > in all cases?\r
  73 > > \r
  74 > > I haven't thought that through, but I'd be glad to hear your ideas.\r
  75 > \r
  76 > This is still an open question if anyone wants to pursue it, (it might\r
  77 > make it simpler to then fix the atomicity bugs with adding new messages\r
  78 > to the database, and only later adjusting the maildir filename).\r
  79 \r
  80 I believe you're right that synchronization could always be done\r
  81 eagerly.  In fact, I believe this is true even with the addition of\r
  82 conjunctive and disjunctive flags.\r
  83 \r
  84 When adding or removing messages, flag synchronization fully dictates\r
  85 all tags in flag2tag (that is, the tags' current states don't matter).\r
  86 It also always examines *all* file names backing the message.  This is\r
  87 a stateless process.  With eager synchronization, the tags may go\r
  88 through some transient states during notmuch new, but will always\r
  89 settle down to the correct set as of the final add or remove for a\r
  90 given message ID.\r
  91 \r
  92 > On that topic, if we decide we do need to defer the tags/flags mapping,\r
  93 > then the real fix is to probably also defer the addition of the filename\r
  94 > to the message document in the database. If we change these things only\r
  95 > at the same time, then we should be able to avoid any problems with\r
  96 > things getting out of synchronization.\r
  97 \r
  98 I'd been thinking about this as a way to break up notmuch new into\r
  99 small, consistent transactions, but I don't think it's necessary since\r
 100 flags can be synchronized eagerly.  In fact, with eager\r
 101 synchronization and one other change, I believe notmuch new can be\r
 102 completely correctly performed in lots of small transactions.\r
 103 \r
 104 The one other change is that currently, if notmuch is interrupted\r
 105 after updating a directory mtime but before processing file removals,\r
 106 a subsequent notmuch new will miss those removals.  This could be\r
 107 brushed under the rug, since notmuch will notice the removal after any\r
 108 other change in that directory.  Or it could be handled correctly by\r
 109 giving directories a "removal mtime" in addition to their current\r
 110 "addition mtime" that is only updated after removals are handled.\r