duplicity-team team mailing list archive
-
duplicity-team team
-
Mailing list archive
-
Message #00095
Re: 0.6.01 picking up too many diffs; incorrectly detects 0 volume increment
Some more incremental investigation:
> Traceback (most recent call last):
> File "./duplicity-bin", line 1197, in <module>
> with_tempdir(main)
> File "./duplicity-bin", line 1190, in with_tempdir
> fn()
> File "./duplicity-bin", line 1172, in main
> incremental_backup(sig_chain)
> File "./duplicity-bin", line 484, in incremental_backup
> globals.backend)
> File "./duplicity-bin", line 252, in write_multivol
> globals.restart.setLastSaved(mf)
> File "./duplicity-bin", line 1065, in setLastSaved
> vi = mf.volume_info_dict[self.start_vol]
> KeyError: 0
In this case the relevant files are empty but existing:
-rw-r--r-- 1 scode scode 100902 Jul 7 18:41 duplicity-full-signatures.20090704T162538Z.sigtar.gz
-rw-r--r-- 1 scode scode 199 Jul 7 18:41 duplicity-full.20090704T162538Z.manifest
-rw-r--r-- 1 scode scode 181 Jul 7 18:41 duplicity-inc.20090704T162538Z.to.20090704T162600Z.manifest
-rw-r--r-- 1 scode scode 20 Jul 7 18:41 duplicity-new-signatures.20090704T162538Z.to.20090704T162600Z.sigtar.gz
-rw------- 1 scode scode 41472 Jul 7 18:41 duplicity-new-signatures.20090704T162600Z.to.20090707T164117Z.sigtar.part
-rw------- 1 scode scode 254 Jul 7 18:41 duplicity-inc.20090704T162600Z.to.20090707T164117Z.manifest.part
-rw------- 1 scode scode 0 Jul 7 18:41 duplicity-new-signatures.20090707T164117Z.to.20090707T164131Z.sigtar.part
-rw------- 1 scode scode 0 Jul 7 18:41 duplicity-inc.20090707T164117Z.to.20090707T164131Z.manifest.part
-rw------- 1 scode scode 0 Jul 7 20:18 duplicity-new-signatures.20090707T164131Z.to.20090707T181854Z.sigtar.part
-rw------- 1 scode scode 0 Jul 7 20:18 duplicity-inc.20090707T164131Z.to.20090707T181854Z.manifest.part
-rw------- 1 scode scode 0 Jul 7 20:19 duplicity-new-signatures.20090707T181854Z.to.20090707T181904Z.sigtar.part
-rw------- 1 scode scode 0 Jul 7 20:19 duplicity-inc.20090707T181854Z.to.20090707T181904Z.manifest.part
-rw------- 1 scode scode 0 Jul 8 18:41 duplicity-new-signatures.20090707T181904Z.to.20090708T164157Z.sigtar.part
-rw------- 1 scode scode 0 Jul 8 18:41 duplicity-inc.20090707T181904Z.to.20090708T164157Z.manifest.part
-rw------- 1 scode scode 0 Jul 8 18:46 duplicity-new-signatures.20090708T164157Z.to.20090708T164634Z.sigtar.part
-rw------- 1 scode scode 0 Jul 8 18:46 duplicity-inc.20090708T164157Z.to.20090708T164634Z.manifest.part
-rw------- 1 scode scode 0 Jul 8 18:53 duplicity-new-signatures.20090708T164634Z.to.20090708T165356Z.sigtar.part
-rw------- 1 scode scode 0 Jul 8 18:53 duplicity-inc.20090708T164634Z.to.20090708T165356Z.manifest.part
-rw------- 1 scode scode 0 Jul 8 19:12 duplicity-new-signatures.20090708T165356Z.to.20090708T171215Z.sigtar.part
-rw------- 1 scode scode 0 Jul 8 19:12 duplicity-inc.20090708T165356Z.to.20090708T171215Z.manifest.part
-rw------- 1 scode scode 0 Jul 8 23:37 duplicity-new-signatures.20090708T171215Z.to.20090708T213729Z.sigtar.part
-rw------- 1 scode scode 0 Jul 8 23:37 duplicity-inc.20090708T171215Z.to.20090708T213729Z.manifest.part
And indeed, the call to get_local_manifest() in duplicity-bin ends up
dispatching to Manifest().from_string(), which receives an empty
string, read from file.
As a result, the self.add_volume_info() in the loop.
If I understand things correctly (and I've always been fuzzy on these
parts of the code), a "manifest" represents volume information for
some set. In practice this is a set of volumes associated with a
"backup", either a full backup or an incremental which is part of a
chain.
In this case, the general issue is that the code fails for any
manifest that is completely empty because we cannot obtain meta-data
information for the "first" volume (start_vol) in
Restart.setLastSaved().
Question: Is the bug that we should handle empty manifests, or is the
bug that a manifast should never exist that is empty (other than as
transient data structures in memory)?
Reading later on we have:
# Checkpoint after each volume so restart has a place to restart.
# Note that until after the first volume, all files are temporary.
if vol_num == 1:
sig_outfp.to_partial()
man_outfp.to_partial()
else:
sig_outfp.flush()
man_outfp.flush()
This suggests to me the bug is the latter (since it's supposed to be
invisible) rather than the former, though at this time I'm not sure
why the attempt to make it invisible doesn't work.
--
/ Peter Schuller
PGP userID: 0xE9758B7D or 'Peter Schuller <peter.schuller@xxxxxxxxxxxx>'
Key retrieval: Send an E-Mail to getpgpkey@xxxxxxxxx
E-Mail: peter.schuller@xxxxxxxxxxxx Web: http://www.scode.org
Attachment:
pgpl3nRE6EGxT.pgp
Description: PGP signature
Follow ups
References
-
0.6.01 picking up too many diffs; incorrectly detects 0 volume increment
From: Peter Schuller, 2009-07-04
-
Re: 0.6.01 picking up too many diffs; incorrectly detects 0 volume increment
From: Peter Schuller, 2009-07-04
-
Re: 0.6.01 picking up too many diffs; incorrectly detects 0 volume increment
From: Peter Schuller, 2009-07-04
-
Re: 0.6.01 picking up too many diffs; incorrectly detects 0 volume increment
From: Kenneth Loafman, 2009-07-06
-
Re: 0.6.01 picking up too many diffs; incorrectly detects 0 volume increment
From: Peter Schuller, 2009-07-06
-
Re: 0.6.01 picking up too many diffs; incorrectly detects 0 volume increment
From: Kenneth Loafman, 2009-07-06
-
Re: 0.6.01 picking up too many diffs; incorrectly detects 0 volume increment
From: Kenneth Loafman, 2009-07-06
-
Re: 0.6.01 picking up too many diffs; incorrectly detects 0 volume increment
From: Peter Schuller, 2009-07-07
-
Re: 0.6.01 picking up too many diffs; incorrectly detects 0 volume increment
From: Kenneth Loafman, 2009-07-07
-
Re: 0.6.01 picking up too many diffs; incorrectly detects 0 volume increment
From: Peter Schuller, 2009-07-07