desktop-packages team mailing list archive

[Rolf Leggewie <1252484@xxxxxxxxxxxxxxxxxx>]

quantal has seen the end of its life and is no longer receiving any
updates. Marking the quantal task for this ticket as "Won't Fix".

** Changed in: duplicity (Ubuntu Quantal)
       Status: Fix Committed => Won't Fix

-- 
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to duplicity in Ubuntu.
https://bugs.launchpad.net/bugs/1252484

Title:
  Possible data loss when restarting in the middle of a deleted file

Status in Duplicity - Bandwidth Efficient Encrypted Backup:
  Fix Released
Status in duplicity package in Ubuntu:
  Fix Released
Status in duplicity source package in Lucid:
  Fix Released
Status in duplicity source package in Precise:
  Fix Released
Status in duplicity source package in Quantal:
  Won't Fix
Status in duplicity source package in Saucy:
  Fix Released

Bug description:
  This was recently fixed in duplicity trunk.  But I'm filing a bug for
  paperwork purposes and for Ubuntu SRUs.

  [Impact]

  When restarting a backup, duplicity may accidentally skip the first
  65k chunk of one of the source files.  This means that when it is
  restored, it will be incomplete/corrupted, resulting in data loss.

  Note that symptoms of this bug are diverse and may look like:
  assert len( patch_seq ) == 1, len( patch_seq )
  or
  assert first.difftype != "diff", patch_seq
  or
  librsync error 103 while in patch cycle

  These are all different results from this root cause.  In all cases,
  it is because chunks of files are missing in your backup.  There is
  nothing we can do to get those chunks back.  But a related patch in
  duplicity 0.6.23 will let you restore the rest of your files (instead
  of just crashing halfway through a restore like 0.6.22 does).  So try
  duplicity 0.6.23 to get a little progress from your broken backups.
  And use duplicity 0.6.23 for all future backups.

  [Test Case]

  Download and install the 'test1.sh' file attached to this bug report, and run it like 'sh test1.sh'.  If it prints the following line, the bug is present:
  Binary files /tmp/source/newfile and /tmp/restore/newfile differ

  Or, follow these manual steps:
  mkdir /tmp/source
  dd if=/dev/urandom of=/tmp/source/bigfile bs=1024 count=5000
  # This next command will intentionally fail after the second volume!
  duplicity full /tmp/source file:///tmp/backup --vol 1 --fail 2 --no-encryption
  mv /tmp/source/bigfile /tmp/source/newfile
  duplicity full /tmp/source file:///tmp/backup --no-encryption
  duplicity restore file:///tmp/backup /tmp/restore --no-encryption
  # This next line will say the files differ if the bug is present
  diff /tmp/source/newfile /tmp/restore/newfile

  [Regression Potential]

  It's a relatively small patch, only affecting the specific case of
  restarting a backup when the file we were in the middle of is no
  longer there.  I'd say minor regression potential.

To manage notifications about this bug go to:
https://bugs.launchpad.net/duplicity/+bug/1252484/+subscriptions