Upon datalad's clone
with git-annex 8.20210630-1~ndall+1 and bundled git 2.24.0
(git-annex)lena:~/.tmp/datalad_temp_check_recklesssutnjo68[adjusted/master(unlocked)]git-annex
$> cat .git/config
[core]
repositoryformatversion = 0
filemode = true
bare = false
logallrefupdates = true
sharedrepository = 1
symlinks = false
[remote "origin"]
url = /home/yoh/.tmp/datalad_temp_check_recklesswnpsqpys
fetch = +refs/heads/*:refs/remotes/origin/*
annex-uuid = a69ecda5-b653-4147-b190-37b7911e3ebc
[branch "master"]
remote = origin
merge = refs/heads/master
[annex "security"]
allowed-url-schemes = http https file
allowed-http-addresses = all
[receive]
denyNonFastforwards = true
[annex]
uuid = 06e1e8e1-32ca-484e-9dd6-daf332da0b36
crippledfilesystem = true
version = 8
[filter "annex"]
smudge = git-annex smudge -- %f
clean = git-annex smudge --clean -- %f
[datalad "clone"]
reckless = shared-group
$> ls -ld .git/annex/index*
-rw-rw---- 1 yoh yoh 209 Jul 7 18:24 .git/annex/index
-rw------- 1 yoh yoh 41 Jul 7 18:24 .git/annex/index.lck
we end up with group non-writeable index.lck, whenever before
it was writeable with annex 8.20210330-1~ndall+1 and git 2.24.0
$> ls -ld .git/annex/index*
-rw-rw---- 1 yoh yoh 209 Jul 7 18:29 .git/annex/index
-rw-rw---- 1 yoh yoh 41 Jul 7 18:29 .git/annex/index.lck
$> git annex version | head -n 1
git-annex version: 8.20210330-1~ndall+1
is that somehow intended (didn't spot anything in CHANGELOG.md) or a regression?
reference: https://github.com/datalad/datalad/issues/5759
I don't think annex.freezecontent-command will affect writing this file though.
This seems to be how to reproduce it:
Not identical modes here, but with an older git-annex the index.lck is 664 not 644.
Also, for some reason git-annex init with that config set complains that "Filesystem allows writing to files whose write bit is not set." And enters an adjusted brach. The older git-annex didn't do that either.
Fixed the problem with git-annex init's probing.
Oh, that's odd, fixing that also fixed the index.lck permissions.
So, the actual cause of the permissions problem is init deciding to enter an adjusted unlocked branch. Entering the branch after init does not result in the problem though. So still need to track down what's happening there, since it can enter the adjusted branch for other reasons.
The bug was making init set annex.crippledfilesystem, and once that's set, git-annex avoids setting file perms, so then it writes index.lck it leaves it at the default permissions.
That might or might not be a problem in some case (eg if some filesystem was detected as crippled but still supported file permissions to a point that write bits need to be added to support core.sharedRepository = group), but the reversion was fixed by fixing init's behavior. So, closing this.
[fixed]tag to actual fix/version)Yes that's the commit. Normally I'd have closed it in the commit but I didn't realize at that point that the commit actually fixed it.