followup; close

This commit is contained in:
Joey Hess 2017-06-06 15:36:10 -04:00
parent 3193d8258b
commit eb79584bfe
No known key found for this signature in database
GPG key ID: DB12DB0FF05F8F38
2 changed files with 34 additions and 0 deletions

View file

@ -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]]

View file

@ -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.
"""]]