I've been looking into how to do that for all the backends, however,
infinite retries is not the option. In this case a simple change from
run_command() to run_command_persist() allows retries. I'll look into a
model we can use to standardize error handling across all the backends.
BTW, the goal is for duplicity to run in the background, unattended, via
scheduling. Backups should be regular and scheduled. You can't do that
if you rely on humans to initiate them.
...Ken
Charles Knowlton wrote:
Maybe there could be an option for how many times you want it to retry
that way the user
has more control over how many times it retries instead of it be
indefinitely
Charles
On Jul 8, 2007, at 1:29 AM, address@hidden wrote:
Eric Evans wrote:
Yes, boto will retry once before raising an exception. The only
situations I've personally encountered where that wasn't enough
were outright outages on Amazon's end.
By contrast, the bitbucket backend will retry every 10 seconds
indefinately, (it seems to be the only backend that does that). I'm not
sure how others feel about that, but it might be rather annoying if
duplicity were being run non-interactively and the error condition
persisted.
I submitted the patch that makes the current S3 backend retry
indefinitely because a single retry consistently failed during my
backups. I agree that the current behavior may be annoying, and can
be improved, but a single retry isn't sufficient.
Bob
_______________________________________________
Duplicity-talk mailing list
address@hidden
http://lists.nongnu.org/mailman/listinfo/duplicity-talk
_______________________________________________
Duplicity-talk mailing list
address@hidden
http://lists.nongnu.org/mailman/listinfo/duplicity-talk
_______________________________________________
Duplicity-talk mailing list
address@hidden
http://lists.nongnu.org/mailman/listinfo/duplicity-talk