Comment 14 for bug 1266763

If you remove the lock before restart you will introduce a small window
where another duplicity task could run, but that would be the only
downside. So, just remove the lock and allow duplicity to try again. It's
simple and if another task gets in, there should be no harm.

BTW, I think locking by default is the correct approach in all of this, at
the cache directory level. Some people run multiple duplicity instances in
parallel, but to different backup dirs. That's perfectly OK.

On Thu, Jan 16, 2014 at 8:32 AM, Louis Bouchard <
<email address hidden>> wrote:

> I am affraid that the whole logic of the patch is incorrect. The reason
> why the test above fails is that, when the "starting backup from the
> beginning" occurs, duplicity does the following :
>
> log.Notice(_("RESTART: The first volume failed to upload
> before termination.\n"
> " Restart is impossible...starting
> backup from beginning."))
> self.last_backup.delete()
> os.execve(sys.argv[0], sys.argv, os.environ)
>
> So the os.execve restart a new duplicity instance while the lock is
> being present, hence the concurrency warning & exit. I think that close
> scrutiny is required in order to implement proper locking.
>
> I'm looking into it, but I would appreciate Ken's vision of my analysis
>
> --
> You received this bug notification because you are subscribed to
> Duplicity.
> https://bugs.launchpad.net/bugs/1266763
>
> Title:
> Race condition between status and backup
>
> Status in Duplicity - Bandwidth Efficient Encrypted Backup:
> In Progress
>
> Bug description:
> 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
>