also sprach Joey Hess <[email protected]> [2014-04-20 22:04 +0200]: > I still don't understand what this bug report is about.
Let's try again:
*** SETUP ********************************************
% GIT_DIR=bare.git git --bare init --shared=group
Initialized empty shared Git repository in
/home/madduck/.tmp/cdt.7Y7ncs/bare.git/
% GIT_DIR=bare.git git annex init bare
init bare ok
(Recording state in git...)
% git clone --shared=group bare.git working
Cloning into 'working'...
done.
warning: remote HEAD refers to nonexistent ref, unable to checkout.
% cd working
% touch a && git annex add a && git annex sync --content && git annex drop a
add a ok
(Recording state in git...)
(merging origin/git-annex into git-annex...)
(Recording state in git...)
commit ok
pull origin
ok
copy a copy a (to origin...) ok
pull origin
ok
(Recording state in git...)
push origin
Counting objects: 19, done.
Delta compression using up to 4 threads.
Compressing objects: 100% (15/15), done.
Writing objects: 100% (19/19), 1.54 KiB | 0 bytes/s, done.
Total 19 (delta 5), reused 0 (delta 0)
To /home/madduck/.tmp/cdt.7Y7ncs/bare.git
* [new branch] git-annex -> synced/git-annex
* [new branch] master -> synced/master
ok
drop a ok
(Recording state in git...)
*** FILE MODES *****************************************
% umask
077
% git annex get
get a (from origin...) ok
(Recording state in git...)
% ls -ld
.git/annex/objects/pX/ZJ/SHA256E-s0--e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855
.git/annex/objects/pX/ZJ .git/annex/objects/pX .git/annex/objects .git/annex
drwx------ 7 madduck madduck 4096 May 28 09:46 .git/annex
drwx------ 3 madduck madduck 4096 May 28 09:46 .git/annex/objects
drwxrwx--- 3 madduck madduck 4096 May 28 09:46 .git/annex/objects/pX
drwxrwx--- 3 madduck madduck 4096 May 28 09:46 .git/annex/objects/pX/ZJ
drwxrwx--- 2 madduck madduck 4096 May 28 09:46
.git/annex/objects/pX/ZJ/SHA256E-s0--e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855
So here is the first problem: .git/annex and .git/annex/objects are
created not according to core.sharedRepository, but according to
umask.
*** GROUP-STICKY BIT ************************************
% git annex drop
drop a ok
(Recording state in git...)
% chgrp -R pm . && find -type d -exec chmod g+s {} + && ls -ld . .git
.git/annex
drwx--S--- 3 madduck pm 4096 May 28 09:44 .
drwx--S--- 10 madduck pm 4096 May 28 09:46 .git
drwx--S--- 7 madduck pm 4096 May 28 09:49 .git/annex
% touch .git/annex/tmp/foo && ls -l .git/annex/tmp/foo && rm
.git/annex/tmp/foo
-rw------- 1 madduck pm 0 May 28 09:50 .git/annex/tmp/foo
This is expected, i.e. the file is created with the group of the
parent folder.
But now look at this:
% ls -ld
.git/annex/objects/pX/ZJ/SHA256E-s0--e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855
.git/annex/objects/pX/ZJ .git/annex/objects/pX .git/annex/objects .git/annex
.git/annex/objects/pX/ZJ/SHA256E-s0--e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855/SHA256E-s0--e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855
drwx--S--- 7 madduck pm 4096 May 28 09:51 .git/annex
drwx--S--- 3 madduck pm 4096 May 28 09:51 .git/annex/objects
drwxrws--- 3 madduck pm 4096 May 28 09:51 .git/annex/objects/pX
drwxrws--- 3 madduck pm 4096 May 28 09:51 .git/annex/objects/pX/ZJ
drwxrws--- 2 madduck pm 4096 May 28 09:51
.git/annex/objects/pX/ZJ/SHA256E-s0--e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855
-r--r----- 1 madduck madduck 0 May 28 09:44
.git/annex/objects/pX/ZJ/SHA256E-s0--e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855/SHA256E-s0--e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855
So the directories are /almost/ created properly, but the actual
file does *not* inherit the group, despite the g+s sticky bit.
And the reason for this is that there's an fchown() call happening
that overrides the group (see strace output in my mail from 6 April,
13:17:33 +0200 <[email protected]>),
presumably by cp-a, which copies the permissions from the source
repository (which has a different group policy).
I think git-annex should make sure that it only transfers content
and leaves file creation and permsission, group, owner (and ACLs!)
up to the policy at the destination, not enforce anything.
Why are you using cp -a for local transfers? I think this is the
core of the problem.
--
.''`. martin f. krafft <[email protected]> Related projects:
: :' : proud Debian developer http://debiansystem.info
`. `'` http://people.debian.org/~madduck http://vcs-pkg.org
`- Debian - when you have better things to do than fixing systems
"was aus liebe getan wird,
geschieht immer jenseits von gut und böse."
- friedrich nietzsche
digital_signature_gpg.asc
Description: Digital signature (see http://martin-krafft.net/gpg/sig-policy/999bbcc4/current)
