11/a7c1127e059dd606051b4514ea45a259b7e442

   1 Return-Path: <cworth@cworth.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 5B751431FC0;\r
   6         Thu, 26 Nov 2009 07:40:30 -0800 (PST)\r
   7 X-Virus-Scanned: Debian amavisd-new at olra.theworths.org\r
   8 Received: from olra.theworths.org ([127.0.0.1])\r
   9         by localhost (olra.theworths.org [127.0.0.1]) (amavisd-new, port 10024)\r
  10         with ESMTP id ZAyzvKl5GQ+J; Thu, 26 Nov 2009 07:40:29 -0800 (PST)\r
  11 Received: from cworth.org (localhost [127.0.0.1])\r
  12         by olra.theworths.org (Postfix) with ESMTP id 95B58431FAE;\r
  13         Thu, 26 Nov 2009 07:40:29 -0800 (PST)\r
  14 From: Carl Worth <cworth@cworth.org>\r
  15 To: Mikhail Gusarov <dottedmag@dottedmag.net>, notmuch@notmuchmail.org\r
  16 In-Reply-To: <1258938805-15961-1-git-send-email-dottedmag@dottedmag.net>\r
  17 References: <1258938805-15961-1-git-send-email-dottedmag@dottedmag.net>\r
  18 Date: Thu, 26 Nov 2009 07:40:15 -0800\r
  19 Message-ID: <87aay9s3a8.fsf@yoom.home.cworth.org>\r
  20 MIME-Version: 1.0\r
  21 Content-Type: text/plain; charset=us-ascii\r
  22 Subject: Re: [notmuch] [PATCH] Handle message renames in mail spool\r
  23 X-BeenThere: notmuch@notmuchmail.org\r
  24 X-Mailman-Version: 2.1.12\r
  25 Precedence: list\r
  26 List-Id: "Use and development of the notmuch mail system."\r
  27         <notmuch.notmuchmail.org>\r
  28 List-Unsubscribe: <http://notmuchmail.org/mailman/options/notmuch>,\r
  29         <mailto:notmuch-request@notmuchmail.org?subject=unsubscribe>\r
  30 List-Archive: <http://notmuchmail.org/pipermail/notmuch>\r
  31 List-Post: <mailto:notmuch@notmuchmail.org>\r
  32 List-Help: <mailto:notmuch-request@notmuchmail.org?subject=help>\r
  33 List-Subscribe: <http://notmuchmail.org/mailman/listinfo/notmuch>,\r
  34         <mailto:notmuch-request@notmuchmail.org?subject=subscribe>\r
  35 X-List-Received-Date: Thu, 26 Nov 2009 15:40:30 -0000\r
  36 \r
  37 On Mon, 23 Nov 2009 07:13:25 +0600, Mikhail Gusarov <dottedmag@dottedmag.net> wrote:\r
  38 > In order to handle message renames the following changes were deemed\r
  39 > necessary:\r
  40 \r
  41 Hi Mikhail,\r
  42 \r
  43 I *really* want this patch in, since I think a lot of current users\r
  44 would really benefit from it. I only see one big problem with it:\r
  45 \r
  46 > Note that after applying this patch notmuch still does not handle copying files\r
  47 > (which is harmless, database will point to the last copy of message found during\r
  48 > 'notmuch new') and deleting files (which is more serious, as dangling entries\r
  49 > will show up in searches).\r
  50 ...\r
  51 > +     } else if (strcmp(notmuch_message_get_filename(message), filename)) {\r
  52 > +         /* Message file has been moved/renamed */\r
  53 > +         _notmuch_message_set_filename (message, filename);\r
  54 \r
  55 With multiple copies of the same message being present in the mailstore\r
  56 as different files, the code above will set the filename of the document\r
  57 to each filename in turn, correct?\r
  58 \r
  59 Now, I *think* that Xapian defect #250 doesn't hit us here\r
  60 currently. But there was an old bug in Xapian that changing just the\r
  61 data of a document would also rewrite all the terms. But we've also\r
  62 talked recently about storing the filename as a term as well, and once\r
  63 we add that, then this code would trigger defect #250 and cause a big\r
  64 slowdown here.\r
  65 \r
  66 So I think the code just needs to verify that the old filename no longer\r
  67 exists before it changes anything in the database. And then if it does\r
  68 still exist, we can get our NOTMUCH_STATUS_DUPLICATE_MESSAGE_ID return\r
  69 value back here.\r
  70 \r
  71 >       } else {\r
  72 >           ret = NOTMUCH_STATUS_DUPLICATE_MESSAGE_ID;\r
  73 >           goto DONE;\r
  74 >       }\r
  75 \r
  76 In this case, the return value is actually wrong. This is the case for\r
  77 adding a message file that already exists in the database. I don't know\r
  78 that we have any users that care about distinguishing this, but if they\r
  79 did, then DUPLICATE isn't right. I suggest returning\r
  80 NOTMUCH_STATUS_SUCCESS here.\r
  81 \r
  82 -Carl\r