Re: Threading bug due to a duplicated reference
On Sat, Mar 19, 2005 at 02:28:14PM +0100, Vincent Lefevre wrote:
> In the attached mailbox, Mutt doesn't thread the two messages together.
> I've tested against the CVS version.
>
> The 07 Mar 2005 message contains:
>
> Message-ID: <422C63ED.8020200@xxxxxxx>
>
> The 16 Mar 2005 message contains:
>
> References: <422C63ED.8020200@xxxxxxx> <422CF970.4060002@xxxxxx>
> <422CFA56.1040203@xxxxxx> <422CFA56.1040203@xxxxxx>
> <422CFBA7.8080001@xxxxxxxxxxx> <9SjygSk1w-B@xxxxxxxxxxxxxxxxx>
> In-Reply-To: <9SjygSk1w-B@xxxxxxxxxxxxxxxxx>
>
> The problem seems to occur because of the duplicated reference
> <422CFA56.1040203@xxxxxx>.
I guess that Mutt thinks of the duplicated IDs as a thread loop,
here in thread.c:
| if (is_descendant (new, thread)) /* no loops! */
| break;
So we have to remove duplicated IDs somewhere before the
loop-detection.
I made a patch to do it while parsing headers.
Give it a try.
--
tamo
--- parse.c.BAK 2005-03-20 15:00:24.000000000 +0900
+++ parse.c 2005-03-20 16:07:40.000000000 +0900
@@ -141,6 +141,30 @@
FREE (&new);
else
{
+ /* If NEW is already in LST, remove the old one.
+ * Because we need only the most recent message-id
+ * for making thread trees. Two identical message-id's
+ * in an env->references could break threads.
+ * - Reported by Vincent, 2005.
+ */
+ LIST *l = lst, *prev = NULL;
+ while (l)
+ {
+ if (!strcmp (l->data, new))
+ {
+ LIST *tmp = l;
+ if (prev)
+ l = prev->next = l->next;
+ else
+ l = lst = lst->next;
+ FREE (&tmp->data);
+ FREE (&tmp);
+ }
+ else
+ prev = l, l = l->next;
+ }
+
+ /* Now LST is ready for merging */
t = (LIST *) safe_malloc (sizeof (LIST));
t->data = new;
t->next = lst;