Merge branch 'master' of ssh://git-annex.branchable.com
This commit is contained in:
commit
069e15db11
9 changed files with 106 additions and 0 deletions
|
@ -0,0 +1,10 @@
|
|||
[[!comment format=mdwn
|
||||
username="https://www.google.com/accounts/o8/id?id=AItOawmBUR4O9mofxVbpb8JV9mEbVfIYv670uJo"
|
||||
nickname="Justin"
|
||||
subject="enable debugging"
|
||||
date="2013-03-18T15:13:53Z"
|
||||
content="""
|
||||
try
|
||||
|
||||
git-annex --debug copy --to storage FILE
|
||||
"""]]
|
|
@ -0,0 +1,8 @@
|
|||
[[!comment format=mdwn
|
||||
username="http://joeyh.name/"
|
||||
nickname="joey"
|
||||
subject="comment 2"
|
||||
date="2013-03-18T15:15:30Z"
|
||||
content="""
|
||||
What version of git-annex are you using? Are your repositories using direct mode? What does --debug output?
|
||||
"""]]
|
|
@ -0,0 +1,25 @@
|
|||
[[!comment format=mdwn
|
||||
username="https://me.yahoo.com/a/2grhJvAC049fJnvALDXek.6MRZMTlg--#eec89"
|
||||
nickname="John"
|
||||
subject="comment 3"
|
||||
date="2013-03-18T15:32:31Z"
|
||||
content="""
|
||||
git-annex version on both machines is 4.20130314. Here is the debug output:
|
||||
|
||||
|
||||
[root@titan BoostPro]# git annex --verbose copy --to storage embt-virtual-machines.tar.xz
|
||||
copy embt-virtual-machines.tar.xz (checking storage...) (to storage...) failed
|
||||
git-annex: copy: 1 failed
|
||||
[root@titan BoostPro]# git annex --debug copy --to storage embt-virtual-machines.tar.xz
|
||||
[2013-03-18 10:31:33 CDT] read: git [\"--git-dir=/tank/Backups/BoostPro/.git\",\"--work-tree=/tank/Backups/BoostPro\",\"show-ref\",\"git-annex\"]
|
||||
[2013-03-18 10:31:33 CDT] read: git [\"--git-dir=/tank/Backups/BoostPro/.git\",\"--work-tree=/tank/Backups/BoostPro\",\"show-ref\",\"--hash\",\"refs/heads/git-annex\"]
|
||||
[2013-03-18 10:31:33 CDT] read: git [\"--git-dir=/tank/Backups/BoostPro/.git\",\"--work-tree=/tank/Backups/BoostPro\",\"log\",\"refs/heads/git-annex..de30985dc380b49f50ae82046934457177b8d273\",\"--oneline\",\"-n1\"]
|
||||
[2013-03-18 10:31:33 CDT] read: git [\"--git-dir=/tank/Backups/BoostPro/.git\",\"--work-tree=/tank/Backups/BoostPro\",\"log\",\"refs/heads/git-annex..678538248a63e4d4da706a4b703938f6b8e58657\",\"--oneline\",\"-n1\"]
|
||||
[2013-03-18 10:31:33 CDT] read: git [\"--git-dir=/tank/Backups/BoostPro/.git\",\"--work-tree=/tank/Backups/BoostPro\",\"log\",\"refs/heads/git-annex..12346a2c23771268e2af5bfa3f813db172493354\",\"--oneline\",\"-n1\"]
|
||||
[2013-03-18 10:31:33 CDT] chat: git [\"--git-dir=/tank/Backups/BoostPro/.git\",\"--work-tree=/tank/Backups/BoostPro\",\"cat-file\",\"--batch\"]
|
||||
[2013-03-18 10:31:33 CDT] read: git [\"--git-dir=/tank/Backups/BoostPro/.git\",\"--work-tree=/tank/Backups/BoostPro\",\"ls-files\",\"--cached\",\"-z\",\"--\",\"embt-virtual-machines.tar.xz\"]
|
||||
copy embt-virtual-machines.tar.xz (checking storage...) [2013-03-18 10:31:33 CDT] call: ssh [\"-T\",\"storage\",\"git-annex-shell 'inannex' '/tank/Backups/BoostPro' 'SHA256E-s51189502084--ad50567a43f10210e7cdae49f91dbfcc449b7f0629795da1fc268993ff59319b.tar.xz' --uuid ad6ef11f-ecad-48d5-af7c-43f8197ac124\"]
|
||||
(to storage...) failed
|
||||
git-annex: copy: 1 failed
|
||||
|
||||
"""]]
|
|
@ -0,0 +1,18 @@
|
|||
[[!comment format=mdwn
|
||||
username="https://pradermecker.myopenid.com/"
|
||||
ip="195.244.162.7"
|
||||
subject="comment 10"
|
||||
date="2013-03-18T15:47:19Z"
|
||||
content="""
|
||||
Ok, I will try that.
|
||||
|
||||
For your information, I have rebuild the aur package inside a VM using the latest master. All tests passed.
|
||||
|
||||
Now I get a new error message with WEBDAV saying:
|
||||
|
||||
```
|
||||
git-annex: WebDAV failed to write file: \"Conflict\": user error
|
||||
```
|
||||
|
||||
As a note the current aur build is rather cumbersome because it needs to rebuild a lot of packages using cabal. I believe this is due to a few missing dependencies in the Arch repos [haskell-core] and [haskell-web] such as uuid, SafeSemaphore or c2hs.
|
||||
"""]]
|
|
@ -0,0 +1,8 @@
|
|||
[[!comment format=mdwn
|
||||
username="https://pradermecker.myopenid.com/"
|
||||
ip="195.244.162.7"
|
||||
subject="comment 11"
|
||||
date="2013-03-18T16:24:52Z"
|
||||
content="""
|
||||
FYI, it is a bit heavy for me to try the standalone version as it is 32 bits only (I am on 64-bits)
|
||||
"""]]
|
|
@ -0,0 +1,9 @@
|
|||
[[!comment format=mdwn
|
||||
username="http://joeyh.name/"
|
||||
nickname="joey"
|
||||
subject="comment 9"
|
||||
date="2013-03-18T15:04:00Z"
|
||||
content="""
|
||||
I think what you need to do is try installing the [Linux standalone tarball](http://downloads.kitenet.net/git-annex/linux/current/) and see if it works with WebDAV. We need to rule out this being a bad build on the Arch side. The Linux standalone tarball works with box.com for me.
|
||||
|
||||
"""]]
|
|
@ -0,0 +1,8 @@
|
|||
[[!comment format=mdwn
|
||||
username="http://joeyh.name/"
|
||||
nickname="joey"
|
||||
subject="comment 9"
|
||||
date="2013-03-18T15:45:19Z"
|
||||
content="""
|
||||
There turned out to be a bug specific to OSX that prevented symlinks being checked into git. The daily sanity check did eventually add them. I fixed this bug yesterday.
|
||||
"""]]
|
|
@ -0,0 +1,12 @@
|
|||
[[!comment format=mdwn
|
||||
username="http://joeyh.name/"
|
||||
nickname="joey"
|
||||
subject="comment 1"
|
||||
date="2013-03-18T15:55:05Z"
|
||||
content="""
|
||||
The git-annex webapp runs some shell commands on the remote it's setting up, in this case the FreeNAS box. It's difficult to do this entirely portably. I have tried to use only POSIX shell compatable commands, that should also work with embedded systems using busybox.
|
||||
|
||||
You can try running the probe yourself at the prompt on the FreeNAS and see how it fails. The command run is:
|
||||
|
||||
echo loggedin;if which git-annex-shell; then echo git-annex-shell; fi;if which rsync; then echo rsync; fi
|
||||
"""]]
|
|
@ -0,0 +1,8 @@
|
|||
[[!comment format=mdwn
|
||||
username="http://joeyh.name/"
|
||||
nickname="joey"
|
||||
subject="comment 3"
|
||||
date="2013-03-18T15:09:53Z"
|
||||
content="""
|
||||
git-annex won't let you change a remote's encryption scheme, as this would make any data stored in the remote using the old scheme be no longer accessible. You need to make a new remote. It should be fine to point the new remote at the same location as the old one, though.
|
||||
"""]]
|
Loading…
Add table
Reference in a new issue