Added a comment
This commit is contained in:
parent
05bd13187d
commit
fe11aaf059
1 changed files with 22 additions and 0 deletions
|
@ -0,0 +1,22 @@
|
|||
[[!comment format=mdwn
|
||||
username="yarikoptic"
|
||||
avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
|
||||
subject="comment 3"
|
||||
date="2017-10-10T17:40:08Z"
|
||||
content="""
|
||||
Found a following comment in the code
|
||||
[[!format haskell \"\"\"
|
||||
{- Normally, blocks writing to an annexed file, and modifies file
|
||||
- permissions to allow reading it.
|
||||
-
|
||||
- When core.sharedRepository is set, the write bits are not removed from
|
||||
- the file, but instead the appropriate group write bits are set. This is
|
||||
- necessary to let other users in the group lock the file. But, in a
|
||||
- shared repository, the current user may not be able to change a file
|
||||
- owned by another user, so failure to set this mode is ignored.
|
||||
-}
|
||||
\"\"\"]]
|
||||
So may be it is a \"Feature\" although killing the whole premise of data safety while using git-annex.
|
||||
|
||||
In my case, shared permissions are primarily to make files/repositories readable by others, so may be I should have not used 'shared' mode anyways, since reading does not need the shared setting
|
||||
"""]]
|
Loading…
Add table
Reference in a new issue