Hello Kurt, 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.5 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! ** Changed in: duplicity (Ubuntu Precise) Status: In Progress => Fix Committed ** Tags added: verification-needed -- 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/1266763 Title: Race condition between status and backup Status in Duplicity - Bandwidth Efficient Encrypted Backup: Fix Released Status in “duplicity” package in Ubuntu: Fix Released Status in “duplicity” source package in Precise: Fix Committed Status in “duplicity” source package in Quantal: Won't Fix Status in “duplicity” source package in Raring: Won't Fix Status in “duplicity” source package in Saucy: Fix Committed Status in “duplicity” source package in Trusty: Fix Released Bug description: N.B. This should not be released until after deja-dup bug 1281066. SRU justification : Race condition exist when two instances of duplicity run in the same cache directory (.cache/duplicity) Impact : Potential corruption of the local cache Fix : Add a lockfile in the local cache & prevent execution of a second instance in the case of the presence of the lockfile Test Case : 1) Run one instance of duplicity : $ sudo mkdir /tmp/backup $ sudo duplicity --exclude=/proc --exclude=/sys --exclude=/tmp / file:///tmp/backup While this command is running execute the following in a separate console : $ sudo duplicity collection-status file:///tmp/backup With the new locking mechanism you will see the following : $ sudo duplicity collection-status file:///tmp/backup Another instance is already running with this archive directory If you are sure that this is the only instance running you may delete the following lockfile and run the command again : /home/ubuntu/.cache/duplicity/3fe07cc0f71075f95f411fb55ec60120/lockfile.lock Regression : In the case of spurrious interruption of duplicity, the lockfile will remain in .cache/duplicity which can prevent future use of duplicity. The cache directory will have to be cleaned as outlined in the error message Original description of the problem : When runnining "duply X status" while running "duply X backup" (sorry, I don't know which duplicity commands are created by duply) due to a race-condition the code of 'sync_archive' might happend to append newly created meta-data files to 'local_spurious' and subsequently delete them. This delete seems to have been the reason that triggered bug 1216921. The race condition is that the backup command constantly creates meta- data files while the status command queries the list of local and remote files independently over a larger time span. This means that a local file might already been remote but the status command did not see it a few seconds ago. To manage notifications about this bug go to: https://bugs.launchpad.net/duplicity/+bug/1266763/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : [email protected] Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
