remove-all-but-n-full does not check for successfull backup

[Stefan Voelkel]

duplicity 0.6.09
Python 2.5.2
Debian Lenny
Target: Linxux, via SSH, no encryption

My backup script contains:

  duplicity --exclude-if-present .duplicity.nobackup --include ... --exclude '**' --archive-dir ... / ssh://...//mnt/duplicity/ --no-encryption --full-if-older-than 180D
  duplicity remove-all-but-n-full 1 ssh://...//mnt/duplicity/ --no-encryption --force

The last full backup was more than 180 days old, so duplicity created a new full backup. However the filesystem was too small, so the new full backup was incomplete.

It seems that the call to remove-all-but-n-full does not check, if the last n full backups were successfull, as it removed the old (complete) full backup, and kept the new (broken) full backup:

$ ls -s
total 529732
    0 duplicity-full.20110306T114016Z.manifest
25612 duplicity-full.20110306T114016Z.vol10.difftar.gz
...
17808 duplicity-full.20110306T114016Z.vol21.difftar.gz
    0 duplicity-full.20110306T114016Z.vol22.difftar.gz
    0 duplicity-full.20110306T114016Z.vol23.difftar.gz
25588 duplicity-full.20110306T114016Z.vol2.difftar.gz
...
25592 duplicity-full.20110306T114016Z.vol9.difftar.gz
    0 duplicity-full-signatures.20110306T114016Z.sigtar.gz

[Barak A. Pearlmutter (bap)]

I found this bug still present in Duplicity 0.8.17-1 on Debian, see https://bugs.debian.org/977546

It would be nice if there were at least a workaround described in the man page, like "run duplicity collection-status LOCATION, and if it says XXX you're okay, but if it says YYY then you may have an incomplete full backup. You can delete an incomplete full backup by running ZZZ."