comment

2 files changed, 47 insertions, 1 deletions

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