bc/6605d2f243c414cec7e3ef24f5281c1094caa5

   1 Return-Path: <novalazy@gmail.com>\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 A2824431FBF\r
   6         for <notmuch@notmuchmail.org>; Mon, 19 Nov 2012 04:26:59 -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: -0.799\r
  10 X-Spam-Level: \r
  11 X-Spam-Status: No, score=-0.799 tagged_above=-999 required=5\r
  12         tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1,\r
  13         FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=disabled\r
  14 Received: from olra.theworths.org ([127.0.0.1])\r
  15         by localhost (olra.theworths.org [127.0.0.1]) (amavisd-new, port 10024)\r
  16         with ESMTP id cPJ7m3Dt8a+u for <notmuch@notmuchmail.org>;\r
  17         Mon, 19 Nov 2012 04:26:58 -0800 (PST)\r
  18 Received: from mail-pa0-f53.google.com (mail-pa0-f53.google.com\r
  19         [209.85.220.53]) (using TLSv1 with cipher RC4-SHA (128/128 bits))\r
  20         (No client certificate requested)\r
  21         by olra.theworths.org (Postfix) with ESMTPS id 7A460431FBC\r
  22         for <notmuch@notmuchmail.org>; Mon, 19 Nov 2012 04:26:58 -0800 (PST)\r
  23 Received: by mail-pa0-f53.google.com with SMTP id bj3so3864810pad.26\r
  24         for <notmuch@notmuchmail.org>; Mon, 19 Nov 2012 04:26:57 -0800 (PST)\r
  25 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;\r
  26         h=date:message-id:from:to:cc:subject:in-reply-to:references\r
  27         :mime-version:content-type:content-disposition\r
  28         :content-transfer-encoding;\r
  29         bh=JhwmViI9MvEQAzpH7eFM97MVgWkcIQlRYZUYpavf1uE=;\r
  30         b=uhoyH/0mfUhzswbl6TQpnkUZ7Cjg7Aq61I8DsO9SKesOCQL4RCSlMi+yg/SL8dWJWa\r
  31         ssRl1aaO2Jr0VnWZeOIKuuXjkAaZrL3FfbWh/roXuN480J0I1G7PdPDVoHgyJLzyqNdw\r
  32         oULm2t6QJPvMs6dil/+mqJsCE3avEtAvMnSpFClmSPUqhCjAnB843w9dj3pfCZ/8XhzN\r
  33         Ajawf2Rfx6WW4/RdMcTbXL4CDCRT7MPkKibwtoviBDWYc8RYaNM58OSK0/NFt/ldMhn0\r
  34         ihhtqphPrBS4fjUu9BJZNLxFvcWm6WYqazRAG36cUkoB21hmA6y3PJ3JQs1GtP6inZAS\r
  35         O24g==\r
  36 Received: by 10.68.231.69 with SMTP id te5mr37984833pbc.81.1353328016628;\r
  37         Mon, 19 Nov 2012 04:26:56 -0800 (PST)\r
  38 Received: from localhost (215.42.233.220.static.exetel.com.au.\r
  39         [220.233.42.215])\r
  40         by mx.google.com with ESMTPS id gu5sm6163419pbc.10.2012.11.19.04.26.53\r
  41         (version=TLSv1/SSLv3 cipher=OTHER);\r
  42         Mon, 19 Nov 2012 04:26:55 -0800 (PST)\r
  43 Date: Mon, 19 Nov 2012 23:26:51 +1100\r
  44 Message-ID: <20121119232651.GB2063@hili.localdomain>\r
  45 From: Peter Wang <novalazy@gmail.com>\r
  46 To: Mark Walters <markwalters1009@gmail.com>\r
  47 Subject: Re: [PATCH 05/18] insert: move file from Maildir tmp to new\r
  48 In-Reply-To: <87haomq0hx.fsf@qmul.ac.uk>\r
  49 References: <1343223767-9812-1-git-send-email-novalazy@gmail.com>\r
  50         <1343223767-9812-5-git-send-email-novalazy@gmail.com>\r
  51         <87haomq0hx.fsf@qmul.ac.uk>\r
  52 MIME-Version: 1.0\r
  53 Content-Type: text/plain; charset=utf-8\r
  54 Content-Disposition: inline\r
  55 Content-Transfer-Encoding: 8bit\r
  56 Cc: notmuch@notmuchmail.org\r
  57 X-BeenThere: notmuch@notmuchmail.org\r
  58 X-Mailman-Version: 2.1.13\r
  59 Precedence: list\r
  60 List-Id: "Use and development of the notmuch mail system."\r
  61         <notmuch.notmuchmail.org>\r
  62 List-Unsubscribe: <http://notmuchmail.org/mailman/options/notmuch>,\r
  63         <mailto:notmuch-request@notmuchmail.org?subject=unsubscribe>\r
  64 List-Archive: <http://notmuchmail.org/pipermail/notmuch>\r
  65 List-Post: <mailto:notmuch@notmuchmail.org>\r
  66 List-Help: <mailto:notmuch-request@notmuchmail.org?subject=help>\r
  67 List-Subscribe: <http://notmuchmail.org/mailman/listinfo/notmuch>,\r
  68         <mailto:notmuch-request@notmuchmail.org?subject=subscribe>\r
  69 X-List-Received-Date: Mon, 19 Nov 2012 12:26:59 -0000\r
  70 \r
  71 On Sun, 18 Nov 2012 17:33:46 +0000, Mark Walters <markwalters1009@gmail.com> wrote:\r
  72 > On Wed, 25 Jul 2012, Peter Wang <novalazy@gmail.com> wrote:\r
  73 > > Atomically move the new message file from the Maildir 'tmp' directory\r
  74 > > to 'new'.\r
  75 > > ---\r
  76 > >  notmuch-insert.c |   18 ++++++++++++++++++\r
  77 > >  1 files changed, 18 insertions(+), 0 deletions(-)\r
  78 > >\r
  79 > > diff --git a/notmuch-insert.c b/notmuch-insert.c\r
  80 > > index 340f7e4..bab1fed 100644\r
  81 > > --- a/notmuch-insert.c\r
  82 > > +++ b/notmuch-insert.c\r
  83 > > @@ -75,6 +75,20 @@ maildir_open_tmp (void *ctx, const char *dir, char **tmppath, char **newpath)\r
  84 > >  }\r
  85 > >  \r
  86 > >  static notmuch_bool_t\r
  87 > > +maildir_move_to_new (const char *tmppath, const char *newpath)\r
  88 > > +{\r
  89 > > +    /* We follow the Dovecot recommendation to simply use rename()\r
  90 > > +     * instead of link() and unlink().\r
  91 > > +     */\r
  92 > > +    if (rename (tmppath, newpath) == 0) {\r
  93 > > +   return TRUE;\r
  94 > > +    }\r
  95 > \r
  96 > Do we want to overwrite an existing message with this name? As far as I\r
  97 > can see rename does overwrite and link would not: was that why rename is\r
  98 > better than link/unlink?\r
  99 > \r
 100 > I would prefer not to overwrite but maybe there is a reason we need to. \r
 101 > Would a possible alternative be to loop when finding a tmp file until\r
 102 > both the tmp file and the new file do not exist?\r
 103 \r
 104 According to [1] it's all pointless -- just generate unique file names.\r
 105 \r
 106 The dovecot maildir-save.c has this comment:\r
 107 \r
 108 /* maildir spec says we should use link() + unlink() here. however\r
 109    since our filename is guaranteed to be unique, rename() works just\r
 110    as well, except faster. even if the filename wasn't unique, the\r
 111    problem could still happen if the file was already moved from\r
 112    new/ to cur/, so link() doesn't really provide any safety anyway.\r
 113 \r
 114    Besides the small temporary performance benefits, this rename() is\r
 115    almost required with OSX's HFS+ filesystem, since it implements\r
 116    hard links in a pretty ugly way, which makes the performance crawl\r
 117    when a lot of hard links are used. */\r
 118 \r
 119 Well, that's one point of view.  I can't say I know any better.\r
 120 \r
 121 Peter\r
 122 \r
 123 [1]: http://wiki.dovecot.org/MailboxFormat/Maildir#Mail_delivery\r