add
This commit is contained in:
parent
7ae8c00c89
commit
eded99d2bd
1 changed files with 22 additions and 0 deletions
22
doc/todo/resuming_encrypted_uploads.mdwn
Normal file
22
doc/todo/resuming_encrypted_uploads.mdwn
Normal file
|
@ -0,0 +1,22 @@
|
||||||
|
Resuming interrupted uploads to encrypted special remotes is not currently
|
||||||
|
possible, because gpg does not produce consistent output. Special remotes
|
||||||
|
that could support resuming include rsync and glacier.
|
||||||
|
|
||||||
|
Without consistent output, git-annex would need to locally cache the encrypted
|
||||||
|
file, and reuse that cache when resuming an upload. This would make
|
||||||
|
encrypted uploads more expensive in terms of both file IO and disk space
|
||||||
|
used.
|
||||||
|
|
||||||
|
[It would be possible to write to the cache at the same time the special
|
||||||
|
remote is being fed data, and if the special remote upload fails, continue
|
||||||
|
writing the rest of the file. That would avoid half the overhead, since
|
||||||
|
the file would not need to be read from, just written to. (Although OS
|
||||||
|
caching may accomplish the same thing.)]
|
||||||
|
|
||||||
|
Also, `git annex unused` would need to show temp files for uploads,
|
||||||
|
the same as it currently shows temp files for downloads, and users would
|
||||||
|
sometimes need to manually dropunused old uploads, that never completed.
|
||||||
|
|
||||||
|
The question, then, is whether resuming uploads is useful enough to add
|
||||||
|
this overhead and user-visible complexity.
|
||||||
|
--[[Joey]]
|
Loading…
Add table
Add a link
Reference in a new issue