mirrors/git-annex
2
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

Added a comment: Fixed a first problem and then ran into bigger problems

Browse source
This commit is contained in:
marek@33e8ba4fbc201af14a2badcc0656024401f5c916 2018-05-31 09:29:30 +00:00 committed by admin
parent bfabce7895
commit abd3e65f34
1 changed files with 19 additions and 0 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

19
doc/forum/Migrate_from_one_connection_mechanism_for_special_remote_to_another/comment_2_db4b772371ee49c743605c728e23c91a._comment Normal file
View file

@ -0,0 +1,19 @@
[[!comment format=mdwn
username="marek@33e8ba4fbc201af14a2badcc0656024401f5c916"
nickname="marek"
avatar="http://cdn.libravatar.org/avatar/65a60e8f5183feeeef8cef815bf73e61"
subject="Fixed a first problem and then ran into bigger problems"
date="2018-05-31T09:29:30Z"
content="""
By using
git show git-annex:remote.log
one can extract the cipher from the old remote and set it with
git annex enableremote $newremote cipher=$CIPHER
However, then I ran into a new problem. The git-annex-remote-hubic special remote created files with leading slashes (/GPGHMACSHA1--00021a41c3143f1e52f16af93625d1072e861543).
Rclone, and I don`t even mean git-annex-remote-rclone, cannot access these files. It interprets the slash as directory separator which leads to those files not being found.
I guess I will just reupload to fix the slash error in the first place. Or find a Hubic client that can deal with slashes and rename the objects remotely.
"""]]