--- /dev/null
+Return-Path: <m.walters@qmul.ac.uk>\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 B0809431FBD\r
+ for <notmuch@notmuchmail.org>; Sun, 20 Apr 2014 00:15:48 -0700 (PDT)\r
+X-Virus-Scanned: Debian amavisd-new at olra.theworths.org\r
+X-Spam-Flag: NO\r
+X-Spam-Score: 0.502\r
+X-Spam-Level: \r
+X-Spam-Status: No, score=0.502 tagged_above=-999 required=5\r
+ tests=[DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001,\r
+ NML_ADSP_CUSTOM_MED=1.2, RCVD_IN_DNSWL_LOW=-0.7] 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 xht2Z1q9FFSB for <notmuch@notmuchmail.org>;\r
+ Sun, 20 Apr 2014 00:15:24 -0700 (PDT)\r
+Received: from mail2.qmul.ac.uk (mail2.qmul.ac.uk [138.37.6.6])\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 C1DB4431FB6\r
+ for <notmuch@notmuchmail.org>; Sun, 20 Apr 2014 00:15:23 -0700 (PDT)\r
+Received: from smtp.qmul.ac.uk ([138.37.6.40])\r
+ by mail2.qmul.ac.uk with esmtp (Exim 4.71)\r
+ (envelope-from <m.walters@qmul.ac.uk>)\r
+ id 1Wblxu-0008NW-Nu; Sun, 20 Apr 2014 08:15:14 +0100\r
+Received: from 94.196.250.77.threembb.co.uk ([94.196.250.77] helo=localhost)\r
+ by smtp.qmul.ac.uk with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.71)\r
+ (envelope-from <m.walters@qmul.ac.uk>)\r
+ id 1Wblxt-0006wl-ST; Sun, 20 Apr 2014 08:15:02 +0100\r
+From: Mark Walters <markwalters1009@gmail.com>\r
+To: David Bremner <david@tethera.net>, notmuch <notmuch@notmuchmail.org>\r
+Subject: [RFC PATCH] Re: excessive thread fusing\r
+In-Reply-To: <87ioq5mrbz.fsf@maritornes.cs.unb.ca>\r
+References: <87ioq5mrbz.fsf@maritornes.cs.unb.ca>\r
+User-Agent: Notmuch/0.15.2+615~g78e3a93 (http://notmuchmail.org) Emacs/23.4.1\r
+ (x86_64-pc-linux-gnu)\r
+Date: Sun, 20 Apr 2014 08:14:56 +0100\r
+Message-ID: <87fvl8mpzj.fsf@qmul.ac.uk>\r
+MIME-Version: 1.0\r
+Content-Type: text/plain; charset=us-ascii\r
+X-Sender-Host-Address: 94.196.250.77\r
+X-QM-Geographic: According to ripencc,\r
+ this message was delivered by a machine in Britain (UK) (GB).\r
+X-QM-SPAM-Info: Sender has good ham record. :)\r
+X-QM-Body-MD5: 71a1118bc27b9b5f9855b6c1b2fb6dba (of first 20000 bytes)\r
+X-SpamAssassin-Score: 0.1\r
+X-SpamAssassin-SpamBar: /\r
+X-SpamAssassin-Report: The QM spam filters have analysed this message to\r
+ determine if it is\r
+ spam. We require at least 5.0 points to mark a message as spam.\r
+ This message scored 0.1 points. Summary of the scoring: \r
+ * 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail\r
+ provider * (markwalters1009[at]gmail.com)\r
+ * 0.1 AWL AWL: From: address is in the auto white-list\r
+X-QM-Scan-Virus: ClamAV says the message is clean\r
+X-BeenThere: notmuch@notmuchmail.org\r
+X-Mailman-Version: 2.1.13\r
+Precedence: list\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: Sun, 20 Apr 2014 07:15:48 -0000\r
+\r
+\r
+On Sat, 19 Apr 2014, David Bremner <david@tethera.net> wrote:\r
+> Gregor Zattler mentioned some problems with threading at \r
+>\r
+> id:20120126004024.GA13704@shi.workgroup\r
+>\r
+> After some off list discussions, I believe I have a smaller test case.\r
+>\r
+> The attached maildir contains 24 messages from the org mode list.\r
+>\r
+> According to notmuch, these form one thread, but I can't figure out\r
+> exactly why. It seems like the chronologically first two messages should\r
+> be a seperate thread. There are several of the infamous malformed ME-E\r
+> In-reply-to headers, but each of these messages also has a References\r
+> header; this seems to indicate a case missed by commit cf8aaafbad68.\r
+\r
+Hi \r
+\r
+I have done dome debugging of this. There is a patch below which fixes\r
+this test case but who knows what it breaks! Please DO NOT apply unless\r
+someone who knows this code says it's OK.\r
+\r
+First, the bug is quite sensitive. The attached 24 messages are numbered\r
+and i will use the last two digits to refer to them (ie the 2 digits are\r
+the ?? in 1397885606.0002??.mbox:2,). The number range from 17-52; 17\r
+and 18 should be one thread and the rest a different thread.\r
+\r
+1) If you add all messages you get one thread. \r
+2) If you add all apart from 52 you get 2 threads. However, then adding\r
+52 still gives two threads.\r
+3) If you add 18 and then 52 you get 1 thread.\r
+4) If you add 17 and 18 then 52 you get 2 threads.\r
+\r
+I think notmuch will use inode sort and since the tar file contains\r
+these three files in the order 18 52 17 we get cases 1 and 2 above.\r
+\r
+I put some debug stuff in _notmuch_database_link_message_to_parents and\r
+I think that the problem comes from the call to parse_references on line\r
+1767 which adds the malformed in-reply-to header to the hash table, so\r
+this malformed line gets added as a potential parent. \r
+\r
+As a clear example that I don't understand this code I don't know why\r
+this no longer causes a problem if message 17 gets added too.\r
+\r
+Best wishes\r
+\r
+Mark\r
+\r
+---\r
+ lib/database.cc | 21 ++++++++++++---------\r
+ 1 file changed, 12 insertions(+), 9 deletions(-)\r
+\r
+diff --git a/lib/database.cc b/lib/database.cc\r
+index 1efb14d..373a255 100644\r
+--- a/lib/database.cc\r
++++ b/lib/database.cc\r
+@@ -1763,20 +1763,23 @@ _notmuch_database_link_message_to_parents (notmuch_database_t *notmuch,\r
+ this_message_id,\r
+ parents, refs);\r
+ \r
+- in_reply_to = notmuch_message_file_get_header (message_file, "in-reply-to");\r
+- in_reply_to_message_id = parse_references (message,\r
+- this_message_id,\r
+- parents, in_reply_to);\r
+-\r
+ /* For the parent of this message, use the last message ID of the\r
+ * References header, if available. If not, fall back to the\r
+- * first message ID in the In-Reply-To header. */\r
++ * first message ID in the In-Reply-To header. We only parse the\r
++ * In-Reply-To header if we need to as otherwise we might\r
++ * contanimate the hash table if it is malformed. */\r
+ if (last_ref_message_id) {\r
+ _notmuch_message_add_term (message, "replyto",\r
+ last_ref_message_id);\r
+- } else if (in_reply_to_message_id) {\r
+- _notmuch_message_add_term (message, "replyto",\r
+- in_reply_to_message_id);\r
++ } else {\r
++ in_reply_to = notmuch_message_file_get_header (message_file, "in-reply-to");\r
++ in_reply_to_message_id = parse_references (message,\r
++ this_message_id,\r
++ parents, in_reply_to);\r
++ if (in_reply_to_message_id) {\r
++ _notmuch_message_add_term (message, "replyto",\r
++ in_reply_to_message_id);\r
++ }\r
+ }\r
+ \r
+ keys = g_hash_table_get_keys (parents);\r
+-- \r
+1.7.10.4\r
+\r
+\r
+\r
+\r
projects / notmuch-archives.git / commitdiff