Date: Mon, 19 Nov 2012 23:26:51 +1100
Message-ID: <20121119232651.GB2063@hili.localdomain>
From: Peter Wang <novalazy@gmail.com>
To: Mark Walters <markwalters1009@gmail.com>
Subject: Re: [PATCH 05/18] insert: move file from Maildir tmp to new
In-Reply-To: <87haomq0hx.fsf@qmul.ac.uk>
References: <1343223767-9812-1-git-send-email-novalazy@gmail.com>
	<1343223767-9812-5-git-send-email-novalazy@gmail.com>
	<87haomq0hx.fsf@qmul.ac.uk>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
Cc: notmuch@notmuchmail.org
Precedence: list

On Sun, 18 Nov 2012 17:33:46 +0000, Mark Walters <markwalters1009@gmail.com> wrote:
> On Wed, 25 Jul 2012, Peter Wang <novalazy@gmail.com> wrote:
> > Atomically move the new message file from the Maildir 'tmp' directory
> > to 'new'.
> > ---
> >  notmuch-insert.c |   18 ++++++++++++++++++
> >  1 files changed, 18 insertions(+), 0 deletions(-)
> >
> > diff --git a/notmuch-insert.c b/notmuch-insert.c
> > index 340f7e4..bab1fed 100644
> > --- a/notmuch-insert.c
> > +++ b/notmuch-insert.c
> > @@ -75,6 +75,20 @@ maildir_open_tmp (void *ctx, const char *dir, char **tmppath, char **newpath)
> >  }
> >  
> >  static notmuch_bool_t
> > +maildir_move_to_new (const char *tmppath, const char *newpath)
> > +{
> > +    /* We follow the Dovecot recommendation to simply use rename()
> > +     * instead of link() and unlink().
> > +     */
> > +    if (rename (tmppath, newpath) == 0) {
> > +	return TRUE;
> > +    }
> 
> Do we want to overwrite an existing message with this name? As far as I
> can see rename does overwrite and link would not: was that why rename is
> better than link/unlink?
> 
> I would prefer not to overwrite but maybe there is a reason we need to. 
> Would a possible alternative be to loop when finding a tmp file until
> both the tmp file and the new file do not exist?

According to [1] it's all pointless -- just generate unique file names.

The dovecot maildir-save.c has this comment:

/* maildir spec says we should use link() + unlink() here. however
   since our filename is guaranteed to be unique, rename() works just
   as well, except faster. even if the filename wasn't unique, the
   problem could still happen if the file was already moved from
   new/ to cur/, so link() doesn't really provide any safety anyway.

   Besides the small temporary performance benefits, this rename() is
   almost required with OSX's HFS+ filesystem, since it implements
   hard links in a pretty ugly way, which makes the performance crawl
   when a lot of hard links are used. */

Well, that's one point of view.  I can't say I know any better.

Peter

[1]: http://wiki.dovecot.org/MailboxFormat/Maildir#Mail_delivery