Re: [PATCH 1/4] emacs: unify search mechanisms
[notmuch-archives.git] / 20 / b5aff948b472994cce841f0a0631af29e587de
1 Return-Path: <amdragon@gmail.com>\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 2CFAB429E21\r
6         for <notmuch@notmuchmail.org>; Sat,  5 Nov 2011 10:26:06 -0700 (PDT)\r
7 X-Virus-Scanned: Debian amavisd-new at olra.theworths.org\r
8 X-Spam-Flag: NO\r
9 X-Spam-Score: -0.699\r
10 X-Spam-Level: \r
11 X-Spam-Status: No, score=-0.699 tagged_above=-999 required=5\r
12         tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FROM=0.001,\r
13         RCVD_IN_DNSWL_LOW=-0.7] 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 YxDwd9dxHKuI for <notmuch@notmuchmail.org>;\r
17         Sat,  5 Nov 2011 10:26:05 -0700 (PDT)\r
18 Received: from mail-gx0-f181.google.com (mail-gx0-f181.google.com\r
19         [209.85.161.181]) (using TLSv1 with cipher RC4-SHA (128/128 bits))\r
20         (No client certificate requested)\r
21         by olra.theworths.org (Postfix) with ESMTPS id 755D1431FB6\r
22         for <notmuch@notmuchmail.org>; Sat,  5 Nov 2011 10:26:05 -0700 (PDT)\r
23 Received: by ggdk6 with SMTP id k6so734362ggd.26\r
24         for <notmuch@notmuchmail.org>; Sat, 05 Nov 2011 10:26:04 -0700 (PDT)\r
25 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;\r
26         h=mime-version:sender:in-reply-to:references:date\r
27         :x-google-sender-auth:message-id:subject:from:to:cc:content-type;\r
28         bh=7xCLuJCB3Ry9FYtSJElz5LFLySWriLHVVqNltD5+nsY=;\r
29         b=gg0rSfFJNeNu6pI7o9P+QIzJ4SvXU83Oup0Dh2icV08ezIep31fxGZwNoCCn5EAmoO\r
30         luFNTDGg94eN6Z6TDwJYvGUzuCKmn9piYS9tDeL+9phtg01g6AnMJU629CBnmCnxC5dS\r
31         k2NU7nXltj4rQZ0F35hKb/V2mPVPyKbm62xpw=\r
32 MIME-Version: 1.0\r
33 Received: by 10.50.156.230 with SMTP id wh6mr23689683igb.17.1320513963638;\r
34         Sat, 05 Nov 2011 10:26:03 -0700 (PDT)\r
35 Sender: amdragon@gmail.com\r
36 Received: by 10.143.166.17 with HTTP; Sat, 5 Nov 2011 10:26:03 -0700 (PDT)\r
37 In-Reply-To: <1317338806-7414-1-git-send-email-thomas@schwinge.name>\r
38 References: <1317338806-7414-1-git-send-email-thomas@schwinge.name>\r
39 Date: Sat, 5 Nov 2011 13:26:03 -0400\r
40 X-Google-Sender-Auth: 9IOARzWfc5xQOr6jmZXl-M1MfM0\r
41 Message-ID:\r
42  <CAH-f9WuE3quh1jneP1Zj4+xB7r+AXwKbX0QfYvEwOQEKFG1F8Q@mail.gmail.com>\r
43 Subject: Re: [PATCH] Repeatability when copying a whole directory into a new\r
44         one.\r
45 From: Austin Clements <amdragon@mit.edu>\r
46 To: Thomas Schwinge <thomas@schwinge.name>\r
47 Content-Type: text/plain; charset=ISO-8859-1\r
48 Cc: notmuch@notmuchmail.org\r
49 X-BeenThere: notmuch@notmuchmail.org\r
50 X-Mailman-Version: 2.1.13\r
51 Precedence: list\r
52 List-Id: "Use and development of the notmuch mail system."\r
53         <notmuch.notmuchmail.org>\r
54 List-Unsubscribe: <http://notmuchmail.org/mailman/options/notmuch>,\r
55         <mailto:notmuch-request@notmuchmail.org?subject=unsubscribe>\r
56 List-Archive: <http://notmuchmail.org/pipermail/notmuch>\r
57 List-Post: <mailto:notmuch@notmuchmail.org>\r
58 List-Help: <mailto:notmuch-request@notmuchmail.org?subject=help>\r
59 List-Subscribe: <http://notmuchmail.org/mailman/listinfo/notmuch>,\r
60         <mailto:notmuch-request@notmuchmail.org?subject=subscribe>\r
61 X-List-Received-Date: Sat, 05 Nov 2011 17:26:06 -0000\r
62 \r
63 On Thu, Sep 29, 2011 at 7:26 PM, Thomas Schwinge <thomas@schwinge.name> wrote:\r
64 > This new test currently fails -- but it shouldn't.\r
65 > ---\r
66 >\r
67 > Hi!\r
68 >\r
69 > I found this while manually copying directories and running notmuch new.\r
70 >\r
71 > Am I just too sleepy at this time, or is it another DB vs. directory\r
72 > mtime issue?\r
73 \r
74 Nice catch.  I haven't verified this, but I believe the problem is\r
75 that notmuch never deletes directory documents.  In fact, there isn't\r
76 even an API to do so.  Even though it detects the deleted directory\r
77 and deletes all messages under it, the directory document sticks\r
78 around.  When the directory comes back, notmuch finds the old\r
79 directory document with the old directory mtime and thinks it doesn't\r
80 have to rescan the directory because the cp -a reproduced the same\r
81 mtime the directory used to have.\r
82 \r
83 So, I guess part of the answer is "don't cp -a" because that mucks\r
84 with mtimes and mtimes are all notmuch has to go by.  But that's no\r
85 excuse for not removing the directory documents when the directory is\r
86 removed.\r
87 \r
88 Fixing this is slightly tricky.  I feel like there *shouldn't* be an\r
89 API to simply remove a directory document because that would let you\r
90 violate database consistency.  Instead, I think the API should\r
91 recursively remove everything under the removed directory, exactly\r
92 like what notmuch-new.c:_remove_directory does right now (plus\r
93 removing the directory documents).  But _remove_directory depends on\r
94 remove_filename, which currently has notmuch-new-specific logic in it.\r
95  I feel like there must be a nice solution to this, and I'm just not\r
96 thinking of it.\r