diff options
author | https://christian.amsuess.com/chrysn <chrysn@web> | 2016-03-15 07:58:08 +0000 |
---|---|---|
committer | admin <admin@branchable.com> | 2016-03-15 07:58:08 +0000 |
commit | 2b4fd841e97264e7295a5880444aa523dea9ca23 (patch) | |
tree | 85123a95d5c398d79bda213095231026121668fb | |
parent | 11d51e70d57cde921d22ed07bd4de198139cb0ae (diff) |
new issue with sharedRepository introdcued in 5.20151208
-rw-r--r-- | doc/bugs/mode_changes_for_sharedRepository_lead_to_permissionDenied_in_fsck.mdwn | 15 |
1 files changed, 15 insertions, 0 deletions
diff --git a/doc/bugs/mode_changes_for_sharedRepository_lead_to_permissionDenied_in_fsck.mdwn b/doc/bugs/mode_changes_for_sharedRepository_lead_to_permissionDenied_in_fsck.mdwn new file mode 100644 index 000000000..c1e1d9e17 --- /dev/null +++ b/doc/bugs/mode_changes_for_sharedRepository_lead_to_permissionDenied_in_fsck.mdwn @@ -0,0 +1,15 @@ +### Please describe the problem. + +When a repository created shared pre 5.20151208 is fsck'd, it spews error messages a la `setFileMode: permission denied (Operation not permitted)` and fails the fsck. + +This seems to be due to the change in file permissions introduced in [[news/5.20151208]] ("When core.sharedRepository is set, annex object files are not made mode 444, since that prevents a user other than the file owner from locking them. Instead, a mode such as 664 is used in this case."). The error message is unclear to a user, though, and does IMO not constitute an error to fail over. + +IMO, failure to set the mode due to ownership issues should be ignored in fsck, and when a user other than the original owner tries to lock a file, they should be presented with an error message a la "Please run `git annex fsck --fast` as <user> to fix the file's permissions". As an alternative or additionally, fsck could show a warning (maybe even an error) that running an additional fsck as all of the other users (explicit list would be nice) to fix all file permissions. + +### Workarounds + +The issue can be resolved for a repository by + +### What version of git-annex are you using? On what operating system? + +This was observed on a git-annex remote pushed to via ssh on debian sid, with pushes from various git-annex versions over the past years. |