From: Jeff King <peff@peff.net>
To: Johan Herland <johan@herland.net>
Cc: Junio C Hamano <gitster@pobox.com>,
git@vger.kernel.org, Duy Nguyen <pclouds@gmail.com>
Subject: Re: [PATCH v2] sha1_file.c:create_tmpfile(): Fix race when creating loose object dirs
Date: Wed, 30 Oct 2013 05:30:17 -0400 [thread overview]
Message-ID: <20131030093017.GA12125@sigill.intra.peff.net> (raw)
In-Reply-To: <20131030091927.GQ11317@sigill.intra.peff.net>
On Wed, Oct 30, 2013 at 05:19:27AM -0400, Jeff King wrote:
> > To achieve this, I guess we have to follow the same procedure we do for
> > loose object creation:
> >
> > 1. Create a temporary directory with a unique name (mkdtemp?)
> >
> > 2. Adjust permissions
> >
> > 3. Rename into place
> >
> > Can this be done sufficiently atomically across all platforms?
>
> Yeah, I think that is the only way to do it. I do not know offhand of
> any platforms that have problems with atomic directory renames, though I
> would not be surprised if some network filesystems don't handle it well.
Actually, thinking on this more, we do not want "rename into place"
semantics, as that usually implies overwrite. We would prefer a
hard-link solution, where only one linker "wins", and the other gets
EEXIST. But you cannot hard-link directories.
POSIX does specify that rename() should return EEXIST rather than
overwriting if the destination directory exists and is not empty. So
in theory that would work, as we would then just be racing against the
other process creating the actual object (and either we replace the
directory with ours before they write the object, or they write the
object first and we get EEXIST).
But I don't know how well that is followed in the real world.
-Peff
prev parent reply other threads:[~2013-10-30 9:30 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-10-27 11:35 [PATCH v2] sha1_file.c:create_tmpfile(): Fix race when creating loose object dirs Johan Herland
2013-10-30 9:19 ` Jeff King
2013-10-30 9:30 ` Jeff King [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20131030093017.GA12125@sigill.intra.peff.net \
--to=peff@peff.net \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=johan@herland.net \
--cc=pclouds@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).