47/b666e3fd72f008f4b913cf58ebeadfe28e7e44

   1 Return-Path: <jrollins@finestructure.net>\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 79650431FBD\r
   6         for <notmuch@notmuchmail.org>; Fri,  5 Feb 2010 08:31:52 -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: -3.733\r
  10 X-Spam-Level: \r
  11 X-Spam-Status: No, score=-3.733 tagged_above=-999 required=5 tests=[AWL=0.266,\r
  12         BAYES_50=0.001, RCVD_IN_DNSWL_MED=-4] autolearn=ham\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 rTc6mvuol5Tb for <notmuch@notmuchmail.org>;\r
  16         Fri,  5 Feb 2010 08:31:51 -0800 (PST)\r
  17 Received: from brinza.cc.columbia.edu (brinza.cc.columbia.edu [128.59.29.8])\r
  18         by olra.theworths.org (Postfix) with ESMTP id 5145A431FAE\r
  19         for <notmuch@notmuchmail.org>; Fri,  5 Feb 2010 08:31:51 -0800 (PST)\r
  20 Received: from servo.finestructure.net (geco.phys.columbia.edu\r
  21         [128.59.170.159])\r
  22         (user=jgr2110 author=jrollins@finestructure.net mech=PLAIN bits=0)\r
  23         by brinza.cc.columbia.edu (8.14.3/8.14.3) with ESMTP id o15GVoiF006947\r
  24         (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT)\r
  25         for <notmuch@notmuchmail.org>; Fri, 5 Feb 2010 11:31:50 -0500 (EST)\r
  26 Received: from jrollins by servo.finestructure.net with local (Exim 4.71)\r
  27         (envelope-from <jrollins@finestructure.net>) id 1NdR5p-0000SR-Vn\r
  28         for notmuch@notmuchmail.org; Fri, 05 Feb 2010 11:31:42 -0500\r
  29 From: Jameson Rollins <jrollins@finestructure.net>\r
  30 To: Notmuch Mail <notmuch@notmuchmail.org>\r
  31 Date: Fri, 05 Feb 2010 11:31:34 -0500\r
  32 Message-ID: <878wb7wsnt.fsf@servo.finestructure.net>\r
  33 MIME-Version: 1.0\r
  34 Content-Type: multipart/signed; boundary="=-=-=";\r
  35         micalg=pgp-sha256; protocol="application/pgp-signature"\r
  36 X-No-Spam-Score: Local\r
  37 X-Scanned-By: MIMEDefang 2.68 on 128.59.29.8\r
  38 Subject: [notmuch] loss of duplicate messages\r
  39 X-BeenThere: notmuch@notmuchmail.org\r
  40 X-Mailman-Version: 2.1.13\r
  41 Precedence: list\r
  42 List-Id: "Use and development of the notmuch mail system."\r
  43         <notmuch.notmuchmail.org>\r
  44 List-Unsubscribe: <http://notmuchmail.org/mailman/options/notmuch>,\r
  45         <mailto:notmuch-request@notmuchmail.org?subject=unsubscribe>\r
  46 List-Archive: <http://notmuchmail.org/pipermail/notmuch>\r
  47 List-Post: <mailto:notmuch@notmuchmail.org>\r
  48 List-Help: <mailto:notmuch-request@notmuchmail.org?subject=help>\r
  49 List-Subscribe: <http://notmuchmail.org/mailman/listinfo/notmuch>,\r
  50         <mailto:notmuch-request@notmuchmail.org?subject=subscribe>\r
  51 X-List-Received-Date: Fri, 05 Feb 2010 16:31:52 -0000\r
  52 \r
  53 --=-=-=\r
  54 Content-Transfer-Encoding: quoted-printable\r
  55 \r
  56 Hey, folks.  I'm noticing a somewhat problematic behavior of notmuch\r
  57 that I was wondering if anyone could comment on.\r
  58 \r
  59 I'm noticing that notmuch is either not syncing, or not returning in\r
  60 searches, duplicate messages that have identical bodies but different\r
  61 headers.  This comes up when I send messages to lists to which I am\r
  62 subscribed.  I have copies of my sent mail saved locally, so I generally\r
  63 have two copies of emails that I send to such lists: the one that I\r
  64 sent, and the one that I receive back from the list.  Here's an example:\r
  65 \r
  66 servo:~ 0$ notmuch search subject:"emacs paned UI"\r
  67 thread:533da424197bb6ba61a42b667d5d8d8f   Wed. 14:12 [2/2] Tad Fisher, Jame=\r
  68 son Rollins; [notmuch] Emacs paned UI ()\r
  69 servo:~ 0$ notmuch count subject:"emacs paned UI"\r
  70 2\r
  71 servo:~ 0$ grep -r -i "emacs paned UI" .mail-notmuch/inbox .mail-notmuch/se=\r
  72 nt\r
  73 .mail-notmuch/inbox/new/1265078715_3.20270.servo,U=3D249614,FMD5=3D7e33429f=\r
  74 656f1e6e9d79b29c3f82c57e:2,:Subject: [notmuch] Emacs paned UI\r
  75 .mail-notmuch/inbox/new/1265224417_0.1998.servo,U=3D250039,FMD5=3D7e33429f6=\r
  76 56f1e6e9d79b29c3f82c57e:2,:Subject: Re: [notmuch] Emacs paned UI\r
  77 .mail-notmuch/sent/cur/1265224340.M66544P992Q1.servo:2,S:Subject: Re: [notm=\r
  78 uch] Emacs paned UI\r
  79 servo:~ 0$=20\r
  80 \r
  81 As you can see, notmuch returns two messages matching the search term,\r
  82 where as a simple grep turns up three, the original message, my\r
  83 response, and my response from the list, the latter two being exact\r
  84 duplicates except for the headers.  The message that notmuch is\r
  85 returning is the one in my sent mail, presumably because it showed up in\r
  86 the index first, and the second identical one was just dropped.\r
  87 \r
  88 I'm not exactly sure what the correct behavior is here, but I would\r
  89 actually like to see my messages sent to the list returned to me.  It's\r
  90 a way of verifying that they did go to the list, as well as getting a\r
  91 feeling for the round trip time.  I personally wouldn't mind just seeing\r
  92 both copies of the message returned by notmuch, as I can just delete one\r
  93 of them if I don't want it to turn up again.  Would this behavior be\r
  94 problematic in any way?  Do folks have suggestions of other behaviors\r
  95 that might get around this problem?\r
  96 \r
  97 jamie.\r
  98 \r
  99 --=-=-=\r
 100 Content-Type: application/pgp-signature\r
 101 \r
 102 -----BEGIN PGP SIGNATURE-----\r
 103 Version: GnuPG v1.4.10 (GNU/Linux)\r
 104 \r
 105 iQIcBAEBCAAGBQJLbEfnAAoJEO00zqvie6q8ybcP/3p3bQmrsk4eFKS8B2nR35Ar\r
 106 Ia5cUydQnb133ftMD+q0gCHWmPJxhAOpCda56rZ51KC+vhikCYORYFCwKApfNzYc\r
 107 CYeyx3y3wII/ntw9NrBe7d7ERlrZZs/+vh7QeaiuuWuhALwXzfwpnCxcHg8v92i/\r
 108 eeedR1/rMOgWayA8NiqIR5SbZFp3kkrI5IUdELPweHExJrFUp4Dfnsb28UB41Zuy\r
 109 diQAxQOQ+IgVZijoPRNI8RUqtod3NoQRuIQtY0e1XwMmF5SgOkkgY6GUN2i67Kth\r
 110 LOjY0SV/k+KXEajIWeeSJIYq25zpN7dBaYJN5EE0uXSMzjp4uSiH2kh47jWj/24c\r
 111 5RC9sJqxs7FOzLXWR45D4NboD+j6fA+Qayb+I0G299NUxP6MM0ac6KceM6jfLsc6\r
 112 f8y0ixGY5sV9GZzi2pJP62dr00LiXrDjMMG+/YRj0l2s2NnkOMJrmY5LuXDCDlSd\r
 113 AYPJZAZlE0KVdNckazg00dHNJvEpLy1ybrBrcl4a5DVAv75zVq9G6FPN/bmOiF8T\r
 114 oTy76xJgFK0FczdIl8eqHYaqlLpubjDooZ2leOo8dZQC685af4qzJPZqqYKBSZbg\r
 115 27aHdCrcXI/8t/Zj/SVO8Zq84OFkbVMna2R/WrRijuE1Mg80f+lIELtpNqKJPujK\r
 116 gOCdOxMAtz3vXp5QDCZI\r
 117 =hQWh\r
 118 -----END PGP SIGNATURE-----\r
 119 --=-=-=--\r