diff options
3 files changed, 50 insertions, 1 deletions
diff --git a/debian/changelog b/debian/changelog index d54548047..41e959ac0 100644 --- a/debian/changelog +++ b/debian/changelog @@ -8,6 +8,9 @@ git-annex (5.20150813) UNRELEASED; urgency=medium * sync: Support --jobs * sync --content: Avoid unnecessary second pull from remotes when no file transfers are made. + * External special remotes can now be built that can be used in readonly + mode, where git-annex downloads content from the remote using regular + http. -- Joey Hess <id@joeyh.name> Wed, 12 Aug 2015 14:31:01 -0400 diff --git a/doc/bugs/UnicodeDecodeError_while_archiving_files_with_git-annex_to_glacier/comment_1_f68d5ad86d67aa73074389cf9a21469e._comment b/doc/bugs/UnicodeDecodeError_while_archiving_files_with_git-annex_to_glacier/comment_1_f68d5ad86d67aa73074389cf9a21469e._comment new file mode 100644 index 000000000..3e5468e63 --- /dev/null +++ b/doc/bugs/UnicodeDecodeError_while_archiving_files_with_git-annex_to_glacier/comment_1_f68d5ad86d67aa73074389cf9a21469e._comment @@ -0,0 +1,22 @@ +[[!comment format=mdwn + username="joey" + subject="""comment 1""" + date="2015-08-14T18:07:10Z" + content=""" +Doesn't seem likely that this is a bug in git-annex. +git-annex is clearly operating on the file just fine until it passes +it off to glacier-cli. + +I suggest you pass --debug to git-annex, and see what glacier-cli command +it's running. That will probably be useful information for the glacier-cli +developers, to reproduce the problem without involving git-annex. + +One possibility that comes to mind, given +<https://github.com/basak/glacier-cli/issues/16> is that your git-annex +repository might be in a path with some characters that glacier-cli doesn't +like in its name. If git-annex passes the full path to the file to +glacier-cli, it might then run into this problem. I'm not sure ATM if +git-annex does pass the full path to the file; it seems like a relative +path would avoid such a problem. The --debug output should answer this +too.. +"""]] diff --git a/doc/design/external_special_remote_protocol.mdwn b/doc/design/external_special_remote_protocol.mdwn index 524271d10..76e57bc69 100644 --- a/doc/design/external_special_remote_protocol.mdwn +++ b/doc/design/external_special_remote_protocol.mdwn @@ -291,7 +291,11 @@ in control. * `SETURLPRESENT Key Url` Records an URL where the Key can be downloaded from. Note that this does not make git-annex think that the url is present on - the web special remote. + the web special remote. + Keep in mind that this stores the url in the git-annex branch. This can + result in bloat to the branch if the url is large and/or does not delta + pack well with other information (such as the names of keys) already + stored in the branch. * `SETURLMISSING Key Url` Records that the key can no longer be downloaded from the specified URL. @@ -339,6 +343,26 @@ quite a long time, especially when the git-annex assistant is using it. The assistant will detect when the system connects to a network, and will start a new process the next time it needs to use a remote. +## readonly mode + +Some storage services allow downloading the content of a file using a +regular http connection, with no authentication. An external special remote +for such a storage service can support a readonly mode of operation. + +It works like this: + +* When a key's content is stored on the remote, use SETURLPRESENT to + tell git-annex the public url from which it can be downloaded. +* When a key's content is removed from the remote, use SETURLMISSING. +* Document that this external special remote can be used in readonly mode. + + The user doesn't even need to install your external special remote + program to use such a remote! All they need to do is run: + `git annex enableremote $remotename readonly=true` + +* The readonly=true parameter makes git-annex download content from the + urls recorded earlier by SETURLPRESENT. + ## TODO * When storing encrypted files stream the file up/down the pipe, rather |