Merge lp:~louis/duplicity/allow-concurrency-manpage into lp:duplicity/0.6

Proposed by Louis Bouchard
Status: Merged
Merged at revision: 954
Proposed branch: lp:~louis/duplicity/allow-concurrency-manpage
Merge into: lp:duplicity/0.6
Diff against target: 19 lines (+9/-0)
1 file modified
bin/duplicity.1 (+9/-0)
To merge this branch: bzr merge lp:~louis/duplicity/allow-concurrency-manpage
Reviewer Review Type Date Requested Status
edso Pending
Review via email: mp+202266@code.launchpad.net

Description of the change

Add option to manpage

To post a comment you must log in.
Revision history for this message
edso (ed.so) wrote :

thanks,

maybe you should mention that the option might be helpful in case duplicity for some reason didn't clean up and the lock file is stale.

..ede/duply.net

955. By Louis Bouchard

Reformat --allow-concurrency text and add mention of stale lockfile

Revision history for this message
Louis Bouchard (louis) wrote :

Good catch ed; just added your suggestion.

Revision history for this message
edso (ed.so) wrote :

this reminded me and i checked. on a quick look at your lockfile addition it seem the lockfile is completely ignored and not refreshed with --allow-concurrency.

so what happens in the case outlined above?
A. shouldn't the stale lockfile be refreshed to the latest instance?
B. shouldn't it at least be deleted after the second duplicity finished.

..ede

Revision history for this message
Louis Bouchard (louis) wrote :

No, the option is to completely override the lockfile usage. Using the option will let duplicity run w/o using the locking mechanism.

If you see this as an issue, please create a new bug and I will work on adding this, it shouldn't be too hard

Revision history for this message
edso (ed.so) wrote :

let's see what Ken says about it.

my vote is, if the lock file is the default mode (which is good) there must be a way to deal with stale locks.

easiest option would be that the most current duplicity run takes over the lock when run with --allow-concurrency and cleans it if finished.
additionally we should clearly state "If you know what you are doing!" to the option's manpage description.

i'd rather save the bug report as this is still unreleased, more work in progress so far.

..ede

Preview Diff

[H/L] Next/Prev Comment, [J/K] Next/Prev File, [N/P] Next/Prev Hunk
1=== modified file 'bin/duplicity.1'
2--- bin/duplicity.1 2013-12-26 14:33:05 +0000
3+++ bin/duplicity.1 2014-01-20 10:11:37 +0000
4@@ -339,6 +339,15 @@
5 .SH OPTIONS
6
7 .TP
8+.BI --allow-concurrency
9+Allow duplicity to run more than one instance in the same user context.
10+Upon startup, duplicity puts a lock file into the cache directory which
11+prevents a second instance of duplicity to run at the same time.
12+Using this option will override the locking mechanism and allow for a
13+second duplicity instance to run. This may become useful when a stale
14+lockfile has been left behind.
15+
16+.TP
17 .BI --allow-source-mismatch
18 Do not abort on attempts to use the same archive dir or remote backend
19 to back up different directories. duplicity will tell you if you need

Subscribers

People subscribed via source and target branches