mirrors/git-annex
2
0
Fork 0
Code Issues Pull requests Projects Releases Packages 1 Wiki Activity Actions

thoughts

Browse source
This commit is contained in:
Joey Hess 2017-05-24 15:14:49 -04:00
parent 77ba430b38
commit 3cc30dd128
No known key found for this signature in database
GPG key ID: DB12DB0FF05F8F38
1 changed files with 42 additions and 0 deletions
Download patch file Download diff file Expand all files Collapse all files

42
doc/todo/export/comment_3_38e0b7bac8f2cfad492704ab6ab81e2b._comment Normal file
View file

@ -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.
"""]]