followup; close
This commit is contained in:
parent
3193d8258b
commit
eb79584bfe
2 changed files with 34 additions and 0 deletions
|
@ -44,3 +44,6 @@ The following will result in the creation of a 'normal' indirect share:
|
|||
### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders)
|
||||
|
||||
Has been working great, so far, except for the above.
|
||||
|
||||
> [[done]]; I think this just doesn't support permissions correcectly, and
|
||||
> there does not appear to be a git-annex bug. --[[Joey]]
|
||||
|
|
|
@ -0,0 +1,31 @@
|
|||
[[!comment format=mdwn
|
||||
username="joey"
|
||||
subject="""comment 1"""
|
||||
date="2017-06-06T19:28:18Z"
|
||||
content="""
|
||||
Lack of support for hard links does not make git-annex enable
|
||||
crippled filesystem mode. Lack of support for either symlinks
|
||||
or unix permissions are the only things that cause that.
|
||||
|
||||
I assume that you've checked that you can create symlinks on the UnRaid.
|
||||
|
||||
Unix permissions may *seem* to work, eg they can be set. However, git-annex
|
||||
checks if they *actually* work, by creating a file, removing the write bit,
|
||||
and trying to write to it. If the write succeeds, the filesystem is not
|
||||
actually honoring permissions.
|
||||
|
||||
Using git-annex in indirect mode with such a filesystem can
|
||||
result in data loss. For example:
|
||||
|
||||
git annex add foo
|
||||
git commit foo -m added
|
||||
echo corrupt > foo
|
||||
|
||||
Here the echo follows the symlink to the single copy of the file in
|
||||
.git/annex/objects/ and ignoring the permissions that don't allow writing
|
||||
it it, overwrites it with other data. `git annex fsck` will then tell you
|
||||
that you've lost the old content of the file.
|
||||
|
||||
So, I don't recommend trying to bypass git-annex's check for crippled
|
||||
filesystems.
|
||||
"""]]
|
Loading…
Add table
Add a link
Reference in a new issue