diff options
Diffstat (limited to 'doc/todo/export')
-rw-r--r-- | doc/todo/export/comment_3_38e0b7bac8f2cfad492704ab6ab81e2b._comment | 42 |
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. +"""]] |