Hello Michael, or anyone else affected,

Accepted duplicity into precise-proposed. The package will build now and
be available at
http://launchpad.net/ubuntu/+source/duplicity/0.6.18-0ubuntu3.4 in a few
hours, and then in the -proposed repository.

Please help us by testing this new package.  See
https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to
enable and use -proposed.  Your feedback will aid us getting this update
out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug,
mentioning the version of the package you tested, and change the tag
from verification-needed to verification-done. If it does not fix the
bug for you, please add a comment stating that, and change the tag to
verification-failed.  In either case, details of your testing will help
us make a better decision.

Further information regarding the verification process can be found at
https://wiki.ubuntu.com/QATeam/PerformingSRUVerification .  Thank you in
advance!

-- 
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 Committed
Status in “duplicity” package in Ubuntu:
  Fix Released
Status in “duplicity” source package in Lucid:
  New
Status in “duplicity” source package in Precise:
  Fix Committed
Status in “duplicity” source package in Quantal:
  Fix Committed
Status in “duplicity” source package in Raring:
  Fix Committed
Status in “duplicity” source package in Saucy:
  Fix Committed

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.

  [Test Case]

  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

-- 
Mailing list: https://launchpad.net/~desktop-packages
Post to     : desktop-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~desktop-packages
More help   : https://help.launchpad.net/ListHelp

Reply via email to