Package: duplicity
Version: 0.4.2-2+sftp+amazons3+compression
Severity: important
Tags: patch
to reproduce: backup anything with --archive-dir (and no encryption for
simplicity's sake, doesn't make any difference for the problem),
then run another --full backup on top of it, and duplicity will bomb
at the end of the backup during some signature cleanup operation.
$ duplicity --no-encryption --archive-dir /tmp/archive --full /etc/apt
file:///tmp/wheretodump
...works fine the first time, leaves the expected files in /tmp/archive
and /tmp/wheretodump
$ duplicity --no-encryption --archive-dir /tmp/archive --full /etc/apt
file:///tmp/wheretodump
Traceback (most recent call last):
File "/usr/bin/duplicity", line 373, in ?
if __name__ == "__main__": main()
File "/usr/bin/duplicity", line 363, in main
if action == "full": full_backup(col_stats)
File "/usr/bin/duplicity", line 144, in full_backup
col_stats.set_values(sig_chain_warning = None).cleanup_signatures()
File "/usr/lib/python2.3/site-packages/duplicity/collections.py", line 613,
in cleanup_signatures
map(SignatureChain.delete, self.other_sig_chains)
File "/usr/lib/python2.3/site-packages/duplicity/collections.py", line 327,
in delete
self.fullsig.delete()
AttributeError: 'str' object has no attribute 'delete'
the same block of code fails if intermediate incremental backups were
made inbetween the fulls. the fix: don't treat bloody strings as objects...
note that the code in the stable version has the same problem.
--- collections.py.broken 2006-02-03 13:44:31.000000000 +1000
+++ collections.py 2006-06-04 11:57:23.000000000 +1000
@@ -323,8 +323,8 @@
# Try to delete in opposite order, so something useful even if
aborted
if self.archive_dir:
for i in range(len(self.inclist)-1, -1, -1):
- self.inclist[i].delete()
- self.fullsig.delete()
+
self.archive_dir.append(self.inclist[i]).delete()
+ self.archive_dir.append(self.fullsig).delete()
else:
assert self.backend
inclist_copy = self.inclist[:]
one logical issue with that code remains, though: i'm unsure of the
consequences of nuking all previous signature sets on full backups. does
that make restoring from these old backups impossible? i sure hope not,
i'm a big fan of keeping quite some old backup sets lying around...
regards
az
-- System Information:
Debian Release: 3.1
APT prefers testing
APT policy: (980, 'testing'), (970, 'unstable')
Architecture: i386 (i686)
Kernel: Linux 2.6.14
Locale: LANG=C, LC_CTYPE=de_AT (charmap=ISO-8859-1)
Versions of packages duplicity depends on:
ii gnupg 1.4.1-1.sarge3 GNU privacy guard - a free PGP rep
ii libc6 2.3.2.ds1-22sarge3 GNU C Library: Shared libraries an
ii librsync1 0.9.7-1 Library which implements the rsync
ii python 2.3.5-2 An interactive high-level object-o
ii python-gnupginterface 0.3.2-6 Python interface to GnuPG (GPG)
-- no debconf information
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
