Re: Filesystem functionality used by notmuch
[notmuch-archives.git] / c1 / acce23326f179249755fbb9df8228c1cc281ba
1 Return-Path: <jani@nikula.org>\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 9B129429E54\r
6         for <notmuch@notmuchmail.org>; Sun, 22 Jan 2012 04:19:11 -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.7\r
10 X-Spam-Level: \r
11 X-Spam-Status: No, score=-0.7 tagged_above=-999 required=5\r
12         tests=[RCVD_IN_DNSWL_LOW=-0.7] 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 kgnVGJ6MODAt for <notmuch@notmuchmail.org>;\r
16         Sun, 22 Jan 2012 04:19:11 -0800 (PST)\r
17 Received: from mail-ee0-f53.google.com (mail-ee0-f53.google.com\r
18  [74.125.83.53])        (using TLSv1 with cipher RC4-SHA (128/128 bits))        (No client\r
19  certificate requested) by olra.theworths.org (Postfix) with ESMTPS id\r
20  CA6F0429E40    for <notmuch@notmuchmail.org>; Sun, 22 Jan 2012 04:19:10 -0800\r
21  (PST)\r
22 Received: by eeke51 with SMTP id e51so1110243eek.26\r
23         for <notmuch@notmuchmail.org>; Sun, 22 Jan 2012 04:19:09 -0800 (PST)\r
24 Received: by 10.14.35.84 with SMTP id t60mr1565865eea.126.1327234749328;\r
25         Sun, 22 Jan 2012 04:19:09 -0800 (PST)\r
26 Received: from localhost (dsl-hkibrasgw4-fe50f800-253.dhcp.inet.fi.\r
27         [84.248.80.253])\r
28         by mx.google.com with ESMTPS id c16sm39153782eei.1.2012.01.22.04.19.06\r
29         (version=SSLv3 cipher=OTHER); Sun, 22 Jan 2012 04:19:08 -0800 (PST)\r
30 From: Jani Nikula <jani@nikula.org>\r
31 To: Austin Clements <amdragon@MIT.EDU>\r
32 Subject: Re: [PATCH] lib: Save filenames for files detected as "not an email\r
33         file" in the database.\r
34 In-Reply-To: <20120121234919.GM16740@mit.edu>\r
35 References: <1327096827-5760-1-git-send-email-amdragon@mit.edu>\r
36         <87lip0acfy.fsf@nikula.org> <20120121234919.GM16740@mit.edu>\r
37 User-Agent: Notmuch/0.11+76~g1de742d (http://notmuchmail.org) Emacs/23.3.1\r
38         (i686-pc-linux-gnu)\r
39 Date: Sun, 22 Jan 2012 14:19:04 +0200\r
40 Message-ID: <87pqecylon.fsf@nikula.org>\r
41 MIME-Version: 1.0\r
42 X-Gm-Message-State:\r
43  ALoCoQmHfJ9fxcs9/qd2mju6sqQVpy5rjwllHMuHqtKGLhUeUrgg5lWLNAH7rtqQeJ1VM8HPZMzN\r
44 Content-Type: text/plain; charset=us-ascii\r
45 Cc: notmuch@notmuchmail.org\r
46 X-BeenThere: notmuch@notmuchmail.org\r
47 X-Mailman-Version: 2.1.13\r
48 Precedence: list\r
49 List-Id: "Use and development of the notmuch mail system."\r
50         <notmuch.notmuchmail.org>\r
51 List-Unsubscribe: <http://notmuchmail.org/mailman/options/notmuch>,\r
52         <mailto:notmuch-request@notmuchmail.org?subject=unsubscribe>\r
53 List-Archive: <http://notmuchmail.org/pipermail/notmuch>\r
54 List-Post: <mailto:notmuch@notmuchmail.org>\r
55 List-Help: <mailto:notmuch-request@notmuchmail.org?subject=help>\r
56 List-Subscribe: <http://notmuchmail.org/mailman/listinfo/notmuch>,\r
57         <mailto:notmuch-request@notmuchmail.org?subject=subscribe>\r
58 X-List-Received-Date: Sun, 22 Jan 2012 12:19:11 -0000\r
59 \r
60 On Sat, 21 Jan 2012 18:49:19 -0500, Austin Clements <amdragon@MIT.EDU> wrote:\r
61 > Quoth Jani Nikula on Jan 22 at  1:00 am:\r
62 > > On Fri, 20 Jan 2012 17:00:27 -0500, Austin Clements <amdragon@MIT.EDU> wrote:\r
63 > > > Later runs of "notmuch new" won't scan these files again and won't\r
64 > > > print warnings.\r
65 > > > \r
66 > > > Various programs (Dovecot, in my case) store indexes and caches and\r
67 > > > such in the maildir.  Without this, notmuch persistently complains\r
68 > > > about such files.\r
69 > > \r
70 > > Overall, sounds good and doing this automagically is nice. Superficially\r
71 > > the code looks sensible, but I didn't really dig into it. A few nasty\r
72 > > questions instead:\r
73 > > \r
74 > > What happens if you delete a non-email file? Does the entry stay in the\r
75 > > database?\r
76\r
77 > Phooey.  I thought this worked, but you're right that it doesn't (I\r
78 > even wrote a test for this, but the test was based on a false\r
79 > assumption).  Non-email files do get returned by the directory\r
80 > iterator, so without any changes, notmuch new will notice that they're\r
81 > gone.  What I missed is that it then uses\r
82 > notmuch_database_find_message_by_filename to find the "message" and\r
83 > remove the filename, which won't work since there's no message to\r
84 > find.\r
85\r
86 > I'll have to think about this more.\r
87 \r
88 Sorry about that...\r
89 \r
90 This feature has considerable overlap with file/subdirectory exclusion,\r
91 most recently referred to in id:"20120122113212.GA7084@X200". I like the\r
92 way your approach is automatic, but doing it manually with configurable\r
93 exclusions has certain explicitness to it, and altogether avoids the\r
94 problems here, don't you think? There apparently also are people who\r
95 wouldn't want notmuch to index some valid email files for one reason or\r
96 another.\r
97 \r
98 I haven't thought this through, but what if the exclude/ignore feature\r
99 had both the option to specify explicit files/subdirs (patterns like\r
100 .gitignore?) that are ignored, and some sort of "auto" option you could\r
101 enable to ignore all non-email files without warnings? This would\r
102 obviously all happen in the cli.\r
103 \r
104 That probably does not make your thinking any easier, I'm afraid... but\r
105 perhaps it provides another angle.\r
106 \r
107 \r
108 BR,\r
109 Jani.\r
110 \r
111 \r
112\r
113 > > What happens if you replace a non-email file with an email file?\r
114\r
115 > It will not notice because notmuch new only inspects directory mtimes.\r
116 > This would require checking the mtimes of every non-email in the\r
117 > database on every notmuch new.\r
118\r
119 > > Does it matter what happens above?\r
120 > > \r
121 > > These are corner cases, but what remains in TODO suggests that it would\r
122 > > be difficult to debug and figure out if the above ever did happen to\r
123 > > someone.\r
124\r
125 > Yes.  It's possible this needs to get a search syntax before it is\r
126 > acceptable for general use.\r
127\r
128 > > BR,\r
129 > > Jani.\r