blob: c422dc903e905c4d6aba8a0e02ccd4516280f195 (
plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
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.
"""]]
|
