Return-Path: X-Original-To: notmuch@notmuchmail.org Delivered-To: notmuch@notmuchmail.org Received: from localhost (localhost [127.0.0.1]) by olra.theworths.org (Postfix) with ESMTP id 79650431FBD for ; Fri, 5 Feb 2010 08:31:52 -0800 (PST) X-Virus-Scanned: Debian amavisd-new at olra.theworths.org X-Spam-Flag: NO X-Spam-Score: -3.733 X-Spam-Level: X-Spam-Status: No, score=-3.733 tagged_above=-999 required=5 tests=[AWL=0.266, BAYES_50=0.001, RCVD_IN_DNSWL_MED=-4] autolearn=ham Received: from olra.theworths.org ([127.0.0.1]) by localhost (olra.theworths.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rTc6mvuol5Tb for ; Fri, 5 Feb 2010 08:31:51 -0800 (PST) Received: from brinza.cc.columbia.edu (brinza.cc.columbia.edu [128.59.29.8]) by olra.theworths.org (Postfix) with ESMTP id 5145A431FAE for ; Fri, 5 Feb 2010 08:31:51 -0800 (PST) Received: from servo.finestructure.net (geco.phys.columbia.edu [128.59.170.159]) (user=jgr2110 author=jrollins@finestructure.net mech=PLAIN bits=0) by brinza.cc.columbia.edu (8.14.3/8.14.3) with ESMTP id o15GVoiF006947 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT) for ; Fri, 5 Feb 2010 11:31:50 -0500 (EST) Received: from jrollins by servo.finestructure.net with local (Exim 4.71) (envelope-from ) id 1NdR5p-0000SR-Vn for notmuch@notmuchmail.org; Fri, 05 Feb 2010 11:31:42 -0500 From: Jameson Rollins To: Notmuch Mail Date: Fri, 05 Feb 2010 11:31:34 -0500 Message-ID: <878wb7wsnt.fsf@servo.finestructure.net> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.68 on 128.59.29.8 Subject: [notmuch] loss of duplicate messages X-BeenThere: notmuch@notmuchmail.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: "Use and development of the notmuch mail system." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Feb 2010 16:31:52 -0000 --=-=-= Content-Transfer-Encoding: quoted-printable Hey, folks. I'm noticing a somewhat problematic behavior of notmuch that I was wondering if anyone could comment on. I'm noticing that notmuch is either not syncing, or not returning in searches, duplicate messages that have identical bodies but different headers. This comes up when I send messages to lists to which I am subscribed. I have copies of my sent mail saved locally, so I generally have two copies of emails that I send to such lists: the one that I sent, and the one that I receive back from the list. Here's an example: servo:~ 0$ notmuch search subject:"emacs paned UI" thread:533da424197bb6ba61a42b667d5d8d8f Wed. 14:12 [2/2] Tad Fisher, Jame= son Rollins; [notmuch] Emacs paned UI () servo:~ 0$ notmuch count subject:"emacs paned UI" 2 servo:~ 0$ grep -r -i "emacs paned UI" .mail-notmuch/inbox .mail-notmuch/se= nt .mail-notmuch/inbox/new/1265078715_3.20270.servo,U=3D249614,FMD5=3D7e33429f= 656f1e6e9d79b29c3f82c57e:2,:Subject: [notmuch] Emacs paned UI .mail-notmuch/inbox/new/1265224417_0.1998.servo,U=3D250039,FMD5=3D7e33429f6= 56f1e6e9d79b29c3f82c57e:2,:Subject: Re: [notmuch] Emacs paned UI .mail-notmuch/sent/cur/1265224340.M66544P992Q1.servo:2,S:Subject: Re: [notm= uch] Emacs paned UI servo:~ 0$=20 As you can see, notmuch returns two messages matching the search term, where as a simple grep turns up three, the original message, my response, and my response from the list, the latter two being exact duplicates except for the headers. The message that notmuch is returning is the one in my sent mail, presumably because it showed up in the index first, and the second identical one was just dropped. I'm not exactly sure what the correct behavior is here, but I would actually like to see my messages sent to the list returned to me. It's a way of verifying that they did go to the list, as well as getting a feeling for the round trip time. I personally wouldn't mind just seeing both copies of the message returned by notmuch, as I can just delete one of them if I don't want it to turn up again. Would this behavior be problematic in any way? Do folks have suggestions of other behaviors that might get around this problem? jamie. --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iQIcBAEBCAAGBQJLbEfnAAoJEO00zqvie6q8ybcP/3p3bQmrsk4eFKS8B2nR35Ar Ia5cUydQnb133ftMD+q0gCHWmPJxhAOpCda56rZ51KC+vhikCYORYFCwKApfNzYc CYeyx3y3wII/ntw9NrBe7d7ERlrZZs/+vh7QeaiuuWuhALwXzfwpnCxcHg8v92i/ eeedR1/rMOgWayA8NiqIR5SbZFp3kkrI5IUdELPweHExJrFUp4Dfnsb28UB41Zuy diQAxQOQ+IgVZijoPRNI8RUqtod3NoQRuIQtY0e1XwMmF5SgOkkgY6GUN2i67Kth LOjY0SV/k+KXEajIWeeSJIYq25zpN7dBaYJN5EE0uXSMzjp4uSiH2kh47jWj/24c 5RC9sJqxs7FOzLXWR45D4NboD+j6fA+Qayb+I0G299NUxP6MM0ac6KceM6jfLsc6 f8y0ixGY5sV9GZzi2pJP62dr00LiXrDjMMG+/YRj0l2s2NnkOMJrmY5LuXDCDlSd AYPJZAZlE0KVdNckazg00dHNJvEpLy1ybrBrcl4a5DVAv75zVq9G6FPN/bmOiF8T oTy76xJgFK0FczdIl8eqHYaqlLpubjDooZ2leOo8dZQC685af4qzJPZqqYKBSZbg 27aHdCrcXI/8t/Zj/SVO8Zq84OFkbVMna2R/WrRijuE1Mg80f+lIELtpNqKJPujK gOCdOxMAtz3vXp5QDCZI =hQWh -----END PGP SIGNATURE----- --=-=-=--