1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
|
[[!tag obnam-wishlist]]
obnam force-lock currently doesn't work. As a workaround, remove the lockfiles (all files named lock inside the repository) by hand.
find [repository path] -name lock -exec rm '{}' \;
--weinzwang
---
I confirm that I see this too. This bug exists because I changed how Obnam uses locks: it now locks
each directory properly, instead of just the per-client directory. However, I haven't fixed "force-lock" to
deal with other locks, so now it's not possible to force the locks for other directories than the per-client
one. This is awkward.
To fix this, Obnam needs to know that it can safely remove the locks. There's two cases:
* the lock was created by some other client; in this case, the user (not Obnam automatically)
needs to decide if it is safe to remove the lock: just running "obnam force-lock" should not
do that, instead the user should provide an option like "--really-force-locks" or something
* the lock was created by the same client, i.e., Obnam running on the same host; in this case,
if the Obnam process no longer exists, the lock can be safely removed, otherwise the locks
should not be removed (again, unless "--really-force-locks" is used)
To implement this, we need Obnam to store the hostname and process id of the Obnam
instance that created the lock, preferably in a way that does not leak sensitive information
easily (don't store the client name in cleartext, but the md5sum of it, or something).
--liw
---
As of 0.27, force-locks unconditionally breaks locks, but the lock files will
contain sufficient information to allow us to be more intelligent about the
breaking of locks in the future.
--kinnison
--
This is not good enough -- I'd like obnam to be able to break locks more kindly --
but it's good enough for 1.0, I think, so removing the blocker tag. --liw
---
Making the lock breaking more benign and intelligent is a
wishlist. Adding tag. --liw
---
Turns out that this will either mean unencrypted locks or not putting
any useful info in lock files. [[done]] --liw
|
