mirrors/git-annex
2
0
Fork 0
Code Issues Pull requests Projects Releases Packages 1 Wiki Activity Actions

avoid annexFileMode special case

Browse source 
This makes annexFileMode be just an application of setAnnexPerm',
which avoids having 2 functions that do different versions of the same
thing.

Fixes some buggy behavior for some combinations of core.sharedRepository
and umask.

Sponsored-by: Jack Hill on Patreon
This commit is contained in:
Joey Hess 2023-04-27 15:57:50 -04:00
parent 67f8268b3f
commit aff37fc208
No known key found for this signature in database
GPG key ID: DB12DB0FF05F8F38
13 changed files with 82 additions and 69 deletions
Download patch file Download diff file Expand all files Collapse all files

6
doc/bugs/wrong_modes_for_some_lock_files_withcoresharedrepository.mdwn
View file

@ -2,13 +2,13 @@ With core.sharedRepository=0666, some lock files get created mode 644
(with umask 0022).
With core.sharedRepository=group, some lock files get created mode 660,
rather than 644 (with umask 0022).
rather than 664 (with umask 0022).
Root of the problem is uses of annexFileMode.
Some callers use noUmask with it, which works in cases other than these (at
least with umask 0022). But in the core.sharedRepository=group case, the
umask is cleared by noUmask, which is why the g+r bit is not set.
umask is cleared by noUmask, which is why the o+r bit is not set.
Some callers don't use noUmask with it, and when
core.sharedRepository=0666, that results in the umask being applied
@ -20,3 +20,5 @@ Fix will probably involve getting rid of annexFileMode, and noUmask, and
creating the lock file with default umask, then fixing up the mode if necessary,
before using it. Ie, the same pattern used everywhere else in git-annex.
--[[Joey]]
> [[fixed|done]] --[[Joey]]