followup

doc/bugs/SMB__58___git_annex_clone_works__44___get_fails_on_transfer_lock/comment_2_8831965ea7abf5ac6fe860d93133fbb1._comment

@@ -0,0 +1,42 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2017-05-11T16:37:35Z"
+ content="""
+`git-annex init` is probably detecting a problem with the filesystem
+allowing writes to files whose permissions don't allow them to be written
+to. Since indirect mode relies on being able to prevent writing to files,
+it enables direct mode. The disabling of symlinks is a side effect of that.
+You can probably get away with using indirect mode, but there is the risk
+of annexed files getting modified and so the old version of files being
+lost.
+
+The pid lock is used for transfer locks when that's enabled.
+
+So, the pid lock creation is failing for some reason. The two likely causes
+would be:
+
+* The pid locking code not working well on OSX. This would not be too
+  surprising.
+
+  But, I gave pid locking on OSX a quick test, by making a repository
+  in my OSX home directory, `git config annex.pidlock true` and doing the
+  same in a clone. Transfers between the repositories worked ok so pid
+  locking seems to at least basically work on OSX.
+
+* Something to do with the SMB filesystem breaking the pid locking code.
+  Perhaps something to do with permissions since as noted `git annex init`
+  seems to have identified a problem with permissions handling.
+
+Could you possibly get a `dtruss` dump of git-annex when this error
+happens? That would narrow down the problem a lot.
+
+I could try to set up SMB etc, but I don't have root access to an OSX
+machine, so am not confident I could replicate the problem.
+
+----
+
+Also, it might overall be better to run git-annex on the Synology NAS.
+Then you don't have to mess with networked filesystems. People have done
+this successfully before.
+"""]]