The result of our email discussion is that the --allow-concurrency
option needs to be removed but the locking mechanism stays. A note will
be added to the error message to indicate the lockfile that needs to be
removed to overturn the locking if it has been left behind from a failed
session.
I switched back the upstream status to In Progress to highlight the fact
that the solution that was merge is now incomplete. I'm starting to work
on a new patsh that should come in shortly
** Changed in: duplicity
Status: Fix Committed => 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:
In Progress
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
