followup; close

doc/bugs/unRAID_shares_treated_as_a_crippled_filesystem.mdwn

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

doc/bugs/unRAID_shares_treated_as_a_crippled_filesystem/comment_1_3698dfec0b4b566b240da53d5e20ae5f._comment

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