Unsubscribing SRU Team & sponsors for now : there is ongoing discussion with upstream on the validity of the --allow-concurrency option so please WAIT AND DO NOT MERGE for now
-- 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 Committed Status in “duplicity” package in Ubuntu: In Progress Status in “duplicity” source package in Precise: In Progress Status in “duplicity” source package in Quantal: In Progress Status in “duplicity” source package in Raring: In Progress Status in “duplicity” source package in Saucy: In Progress Status in “duplicity” source package in Trusty: In Progress Bug description: 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 To disable the locking mechanism, the --allow-concurrency option can be used : $ sudo duplicity --allow-concurrency collection-status file:///tmp/backup Local and Remote metadata are synchronized, no sync needed. Last full backup date: Mon Jan 20 17:11:39 2014 Collection Status ----------------- Connecting with backend: LocalBackend Archive dir: /home/ubuntu/.cache/duplicity/ba8d32ccb88d13597b4784252744fc75 Found 0 secondary backup chains. Found primary backup chain with matching signature chain: ------------------------- Chain start time: Mon Jan 20 17:11:39 2014 Chain end time: Mon Jan 20 17:11:39 2014 Number of contained backup sets: 1 Total number of contained volumes: 3 Type of backup set: Time: Num volumes: Full Mon Jan 20 17:11:39 2014 3 ------------------------- No orphaned or incomplete backup sets found. 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 or the --allow-concurrency option will be needed 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
