** Description changed:
+ 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.
** Changed in: duplicity (Ubuntu Quantal)
Status: Triaged => In Progress
** Changed in: duplicity (Ubuntu Raring)
Status: Triaged => In Progress
** Changed in: duplicity (Ubuntu Saucy)
Status: Triaged => In Progress
--
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
