Paramiko backend: delete() always fails if --num-retries > 1

I have this issue, and found the same thing. I do a full every 30 days and clean up any older than 30 days. The problem with the default of --num-retries > 1 default is that we only get to clean up 1 day as we either error out or segfault (sometimes). We keep stacking up old backups as we don't remove more than 1 per backup run, but we are adding 1 backup per backup run for a daily run.

I have changed my script to use --num-retries 1, and now things work fine.

I am using:
Duplicity version 0.6.21
scp back end.

I have tried with --extra-clean --force and found that they are not enough to get the job done. If I do the clean-up on the disk where the files reside using the file back end, things work. This seems specific to the scp back end.

Here are examples I tried:
duplicity --allow-source-mismatch --ssh-askpass remove-older-than 30D --extra-clean --no-encryption --force scp://user@host//path/host//filesystem

This would return to the shell with 50 for an error for the file not found, or 139 if the program segfaulted (happened sometimes, but not always).

If I added --num-retries 1 after the --extra-clean, it works fine.

Gee... finally found that asshole of a bug.

What happened was, that "delete" tried to delete a file global.num_retries-often - even when it was deleted successfully the first time.

Attached a patch. Please include it soon - I know a bunch of people have this problem.

Nice catch!
--num-retries 1
worked for me as a temporary fix: remove-all-but-n-full finally worked as expected on an scp-backend.

The patch works for me, unfortunately hasn't found its way into Ubuntu 13.04's duplicity-0.6.21 package yet. Thanks, Andreas!

Unfortunately still present in Ubuntu 13.10 (0.6.21-0ubuntu4.1).