Comment 4 for bug 1266763

I'm assuming you mean to allow the lockfile to keep duplicity from
operating on the same backup, or do you intend to keep duplicity from
running two or more backups at the same time. This solution solves the
problem of the same backup only if the user issues subsequent commands with
the same lockfile name. I think we should probably just put the lockfile
in the local cache, under a fixed name. That would take some of the burden
off the user, which is the weak link in the chain.

On Mon, Jan 13, 2014 at 8:56 AM, Kurt Huwig <email address hidden> wrote:

> My patch has a dependency on "python-lockfile".
>
> --
> 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:
> New
>
> 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
>