Re: [PATCH 2/4] reftable/stack: register new tables as tempfiles
- From
Patrick Steinhardt <ps@pks.im>
- Date
- Mar 7, 2024, 06:17 UTC
- Message-ID
- <Zelb8ldHh4Lnlh7Z@tanuki>
- In-Reply-To
- <xmqqedcntj06.fsf@gitster.g>
On Wed, Mar 06, 2024 at 08:36:25AM -0800, Junio C Hamano wrote:
Show 20 quoted lines
> Patrick Steinhardt <ps@pks.im> writes: > > >> Since the tempfile is now being created through the tempfile API, I > >> think the file mode can be set directly through `mks_tempfile_m()` > >> instead of creating the tempfile and then using chmod. Just something I > >> thought to mention. > > > > Unfortunately not. The problem is that `mks_tempfile_m()` will munge > > passed-in permissions via "core.sharedRepository", but we already pre > > calculated the target mode in `config.default_permissions`. Thus, the > > result would have wrong permissions if we used `mks_tempfile_m()`. > > I somehow found that default_permissions thing always disturbing. > > Even if we keep a separate mechanism for determining the file > permission (perhaps in order to give ourselves a better separation > as "an independent library" from the rest of Git), shouldn't the > permission setting that is computed by the mechanism and stored in > config.default_permissions be consistent with the permission the > rest of git computes based on core.sharedRepository?
It is consistent. The problem is rather that `mks_tempfile_m()` takes a mode as input, but still ends up applying the umask to that mode. Thus, using that function without a subsequent call to chmod(3P) would end up mishandling "core.sharedRepository".
Patrick