43 lines
1.9 KiB
Text
43 lines
1.9 KiB
Text
|
[[!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.
|
||
|
"""]]
|