Please describe the problem.
ATM I am chasing a problem that somehow one key "mutated" although I do not remember doing anything malicious, file seems to be also not writable (itself). So I decided to fsck, and only spotted a problem when some warnings started to appear that I am not the owner of the (key)file. So I looked inside and found that all key dirs are writeable BUT annex complains only about the ones where it can't change permissions since they don't belong to me
What version of git-annex are you using? On what operating system?
6.20170815+gitg22da64d0f-1~ndall+1
Please provide any additional information below.
$> for f in sub00{1,3}/anatomy/highres001.nii.gz; do ls -ld $(realpath $f | xargs dirname ); git annex fsck $f; done
drwxrws--- 2 yoh famface 3 May 12 15:15 /data/famface/openfmri/data/.git/annex/objects/08/V3/SHA256E-s6498717--b850ac82ec9db2d399962609e9381d9c2bdf1f426012500b7005b173ea4d9102.nii.gz/
fsck sub001/anatomy/highres001.nii.gz (checksum...) ok
(recording state in git...)
drwxrwsr-x 2 contematto famface 3 Jul 13 2015 /data/famface/openfmri/data/.git/annex/objects/x2/xX/SHA256E-s6592524--dccba651dc4cd104826a05a2efb6a257b39ca2d8b44d215027250221729f9434.nii.gz/
fsck sub003/anatomy/highres001.nii.gz
** Unable to set correct write mode for .git/annex/objects/x2/xX/SHA256E-s6592524--dccba651dc4cd104826a05a2efb6a257b39ca2d8b44d215027250221729f9434.nii.gz/SHA256E-s6592524--dccba651dc4cd104826a05a2efb6a257b39ca2d8b44d215027250221729f9434.nii.gz ; perhaps you don't own that file
(checksum...) ok
(recording state in git...)
# thought to see may be annex would complain then!?
$> chmod a+rwx /data/famface/openfmri/data/.git/annex/objects/08/V3/SHA256E-s6498717--b850ac82ec9db2d399962609e9381d9c2bdf1f426012500b7005b173ea4d9102.nii.gz/
$> for f in sub00{1,3}/anatomy/highres001.nii.gz; do ls -ld $(realpath $f | xargs dirname ); git annex fsck $f; done
drwxrwsrwx 2 yoh famface 3 May 12 15:15 /data/famface/openfmri/data/.git/annex/objects/08/V3/SHA256E-s6498717--b850ac82ec9db2d399962609e9381d9c2bdf1f426012500b7005b173ea4d9102.nii.gz/
fsck sub001/anatomy/highres001.nii.gz (checksum...) ok
(recording state in git...)
drwxrwsr-x 2 contematto famface 3 Jul 13 2015 /data/famface/openfmri/data/.git/annex/objects/x2/xX/SHA256E-s6592524--dccba651dc4cd104826a05a2efb6a257b39ca2d8b44d215027250221729f9434.nii.gz/
fsck sub003/anatomy/highres001.nii.gz
** Unable to set correct write mode for .git/annex/objects/x2/xX/SHA256E-s6592524--dccba651dc4cd104826a05a2efb6a257b39ca2d8b44d215027250221729f9434.nii.gz/SHA256E-s6592524--dccba651dc4cd104826a05a2efb6a257b39ca2d8b44d215027250221729f9434.nii.gz ; perhaps you don't own that file
(checksum...) ok
(recording state in git...)
btw -- the same wrong permissions on the upper hash directories, and they do not get fixed/complained about at all (that is ok)
I think you must have core.sharedRepository set to group or all or something like that, otherwise fsck never complains about modes.
In general, it's out of scope for fsck to make file permission sane, because "sane" has a fairly broad set of definitions when it comes to file permissions!
See bd516af734bf5e1f7a3d43c7e4dd0f6fb9fd5919 for the backstory about why fsck wants to fix this one particular permission. In short, old versions of git-annex didn't set the write bit of content files in a shared repo, which prevented git-annex from locking the content files, which prevents dropping them or locking them to prevent removal while dropping them from another repo. So fsck is fixing up from that situation.
With core.sharedrepository=1, isContentWritePermOk wants owner and group write bits to be set on the content file.
I can reproduce what seems to be the same problem as follows:
When I fsck as user joey, who is in group netdev, it complains it can't fix the permissions.
While joey has write access to the directory containing the content file, this does not allow changing the permissions of the file.
The directory perms do allow deleting the file and replacing it with a copy that has the permissions I want. But, that is an expensive operation, needing to copy a perhaps enormous file. So I don't think it's a reasonable thing for fsck to do.
So, it seems to me that fsck complaining is ok.
FWIW regarding
I prefer machines to do the job instead of me, even though they need to sweat may be more than I for some of those
not sure if needs to be an option or default behavior. But altogether, I am trying to get away from shared mode (ref: http://git-annex.branchable.com/bugs/--shared_setting_of_git_causes_annex39ed_files_to_be_writeable33/) with write permissions set on fiels since it is simply too dangerous if that repository is the single source of correct data/files.
Making fsck use additional disk space by making a copy of an annexed file in an obscure corner case is the kind of thing that results in complaints. It violates least surprise.
The error message seems good.