This bug was fixed in the package duplicity - 0.6.18-0ubuntu3.5
---------------
duplicity (0.6.18-0ubuntu3.5) precise; urgency=low
* debian/patches/14-lp946988-fix-gnupassphrase-error.dpatch
- Backport upstream modification applied in LP: #946988 that fix
a failure to resume a backup with "bad passphrase" when the proper
passphrase is being used.
* debian/patches/13-lp1266763-add-concurrency-locking.dpatch
- Implement locking mechanism to avoid concurrent execution under the same
cache directory. This functionality adds a dependency to python-lockfile
Fixes LP: #1266763
* debian/patches/12-lp1266753-exception-if-no-s3.dpatch
- Add exception handling in the case where no S3 connection is
available instead of silently deleting the local cache.
Fixes LP: #1266753
-- Louis Bouchard <louis.bouch...@ubuntu.com> Thu, 23 Jan 2014 10:16:32 +0100
** Changed in: duplicity (Ubuntu Precise)
Status: Fix Committed => Fix Released
--
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/1266753
Title:
Boto backend removes local cache if connection cannot be made
Status in Duplicity - Bandwidth Efficient Encrypted Backup:
Fix Released
Status in “duplicity” package in Ubuntu:
In Progress
Status in “duplicity” source package in Precise:
Fix Released
Status in “duplicity” source package in Quantal:
In Progress
Status in “duplicity” source package in Saucy:
Fix Released
Bug description:
N.B. This should not be released until after deja-dup - bug 1281066.
SRU Justification
[Impact]
* When there is no connection to the S3 backend, the local cache files are
deleted.
[Test Case]
1. disable the connection to S3
2. run a "collection-status" (basically I run 'duply X status')
[Regression Potential]
* Already fixed in latest duplicity. Needs to be fixed in lockstep with
deja-dup as it Breaks: deja-dup (<< 27.3.1-0ubuntu2 ).
--
When there is no connection to the S3 backend, the local cache files
are deleted. To reproduce:
1. disable the connection to S3
2. run a "collection-status" (basically I run 'duply X status')
You'll get a bunch of these:
Deleting local
/srv/duply-cache/duply_srv/duplicity-inc.20140106T010002Z.to.20140107T010002Z.manifest
(not authoritative at backend).
Deleting local
/srv/duply-cache/duply_srv/duplicity-new-signatures.20131211T124323Z.to.20131211T124519Z.sigtar.gz
(not authoritative at backend).
This is fatal if you run it in a configuration using GPG and having
only the public key for encryption as well as a separate signing key.
Then you cannot backup any more, as the decrypted local cache has been
deleted and the files on the S3 are encrypted.
Probably reason:
There is no check if the connection to the backend could be
established
Workaround:
If you replace at
http://bazaar.launchpad.net/~duplicity-
team/duplicity/0.6-series/view/head:/duplicity/backends/_boto_single.py#L270
the line
return []
with
return None
Then duplicity will crash instead of deleting the local files. Not the
proper solution but at least you can do a backup when the connection
comes back up.
To manage notifications about this bug go to:
https://bugs.launchpad.net/duplicity/+bug/1266753/+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
