Re: [PATCH] sha1_file.c:create_tmpfile(): Fix race when creating loose object dirs
- From
Junio C Hamano <gitster@pobox.com>
- Date
- Oct 22, 2013, 18:09 UTC
- Message-ID
- <xmqqhac9tbx0.fsf@gitster.dls.corp.google.com>
- In-Reply-To
- <CALKQrgdAhLZStLUquizkW_t6wVQsWs0hpGauEm8NjB6tZ67JFw@mail.gmail.com>
Johan Herland <johan@herland.net> writes:
Show 16 quoted lines
>> 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.