duplicity-team team mailing list archive

[Kenneth Loafman <kenneth@xxxxxxxxxxx>]

How about using the wrapper that Mike did for things like par for this?

As for the write command you mentioned, all backends need to be that way.
 We could put a file in the cache that had the current upload state of all
files.  We need to think about this some.  I'd like to see more async
capabilities, but we seem to have users that run their systems at 99% disk
capacity all the time.  Can't async if you don't have the room.

As for restarting, it's in class Restart in bin/duplicity.  We look at the
manifest and go from there.  I'd have to do a deep dive to figure it all
out again.

...Ken



On Mon, Jun 16, 2014 at 5:08 PM, <edgar.soldin@xxxxxx> wrote:

> hi Ken,
>
> just thinking again about my idea to implement a
>  duplicity copy <srcurl> <trgurl>
> and eventually a
>  duplicity sync <srcurl> <trgurl>
>
> these actions would be useful to horcrux (distribute) backup or even other
> data between backends.
>
> in order to successfully mirror/copy a repository i wonder how to best
> implement a save write command that ensures that the file landed on the
> backend. as we do not have a generic remote rename command, uploading a
> part file and renaming it after successful finish is out of question.
> a journaled approach, placing a trigger file that signals a file is about
> to be uploaded, upload it and delete the trigger file afterwards seems a
> probably solution.
>
> here's the question:
> how does the restarting you implemented know that there is an unfinished
> chain on the backend and at which volume it does have to resume?
>
> thx.. ede
>