All of lore.kernel.org
 help / color / mirror / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: Johan Herland <johan@herland.net>
Cc: Jeff King <peff@peff.net>, Duy Nguyen <pclouds@gmail.com>,
	Git Mailing List <git@vger.kernel.org>
Subject: Re: [PATCH] sha1_file.c:create_tmpfile(): Fix race when creating loose object dirs
Date: Tue, 22 Oct 2013 11:09:47 -0700	[thread overview]
Message-ID: <xmqqhac9tbx0.fsf@gitster.dls.corp.google.com> (raw)
In-Reply-To: CALKQrgdAhLZStLUquizkW_t6wVQsWs0hpGauEm8NjB6tZ67JFw@mail.gmail.com

Johan Herland <johan@herland.net> writes:

>> Agreed.  We may notice the failure to correct the permissions in the
>> new code, where the old code left existing directories incorrect
>> permissions as they were.
>
> I'm trying to mentally construct a scenario where two writers with
> different configuration contexts ...
> This case is unfortunate, but no different than if steps 3 and 4 are
> swapped, i.e. the case where fetch B fails because the repo is not yet
> group-writable. Also, remember that as part of changing
> core.sharedRepository like this (step 3), we also require the admin to
> manually alter the permission bits of existing object dirs, to make
> sure they are group-writable (call this step 3.5). All of this has to
> happen _while_ fetch A is running.
>
> Trying to code around this (frankly insane) case in the
> create_tmpfile()/adjust_shared_perm() code is IMHO silly.

I agree.  Note that "We may notice" above were not meant as "we
would fail unnecessarily in some cases where we did not, which is a
regression".  Both the old and the new code will have problems when
two different users race with each other while having umask that is
unsuitable for working together.

      parent reply	other threads:[~2013-10-22 18:09 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-10-18 13:17 [PATCH] sha1_file.c:create_tmpfile(): Fix race when creating loose object dirs Johan Herland
2013-10-18 13:53 ` Eric Sunshine
2013-10-18 14:52   ` Johan Herland
2013-10-18 15:58     ` Eric Sunshine
2013-10-18 13:55 ` Duy Nguyen
2013-10-18 14:00   ` Duy Nguyen
2013-10-18 15:41     ` Johan Herland
2013-10-18 19:05       ` Jeff King
2013-10-18 19:24         ` Junio C Hamano
2013-10-18 23:45           ` Johan Herland
2013-10-19  2:53             ` Jeff King
2013-10-22 18:09             ` Junio C Hamano [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=xmqqhac9tbx0.fsf@gitster.dls.corp.google.com \
    --to=gitster@pobox.com \
    --cc=git@vger.kernel.org \
    --cc=johan@herland.net \
    --cc=pclouds@gmail.com \
    --cc=peff@peff.net \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.