thoughts

1 files changed, 42 insertions, 0 deletions

diff --git a/doc/todo/export/comment_3_38e0b7bac8f2cfad492704ab6ab81e2b._comment b/doc/todo/export/comment_3_38e0b7bac8f2cfad492704ab6ab81e2b._comment
new file mode 100644
index 000000000..307ff40a7
--- /dev/null
+++ b/doc/todo/export/comment_3_38e0b7bac8f2cfad492704ab6ab81e2b._comment
@@ -0,0 +1,42 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 3"""
+ date="2017-05-24T18:59:30Z"
+ content="""
+`storeKey` could not be used for this, so it would need a new remote method
+to store a file on the remote under a specified name. Call it `storeFile`.
+
+What should `storeFile` with an encrypted special remote do? Encrypting
+the data does not seem very useful, especially for hybrid and shared
+where the secret key is embedded in the git repo. Not encrypting the data
+is surely a least surprise violation that would be a security hole.
+So probably best to not support exporting to encrypted special remotes.
+
+`git annex export --to specialremote` cannot handle incremental updates,
+resuming uploads etc, because special remotes can be so limited they only
+support putting the whole content of a file. Even resuming interrupted
+uploads is problimatic, because we don't know for sure what key was
+(partially or completely) exported before. The best that seems doable
+is to make `storeFile` avoid resending the file if the remote has the file
+on it already, and move the file into place atomically once it's all sent. 
+
+Then `git annex export --to remote` could be run repeatedly to export files
+until everything gets exported.
+
+But, when a file has been modified, that would prevent the modified version
+being exported. Unless state is stored somewhere to say that the given file
+on a remote is the content of a given key.
+That state could take the form of a .git-annex/filename.exported stored
+on the remote, which contains the name of the key. When exporting a new
+key over an existing file, that would be overwritten. (Really needs to be
+done atomically..)
+
+What about deleted files? Should export somehow notice that a file
+has been deleted locally, and remove it from the remote? How?
+
+----
+
+Alternatively, leave the incremental updating, deletion etc to
+third-party tools, and have `git annex export` simply export the current
+files to a directory.
+"""]]