Re: [Gnu-arch-users] Re: More archive corruption!!

[Stefan Monnier]

>>> If there is a held one in the parent dir then it happened presumably
>>> because some earlier attempt to commit was interrupted.
>> Doesn't tla catch this interrupt and clean up the lock before
>> exiting?
> It could and perhaps should but the problem could still occur if, for
> example, a network connection to an archive were lost.   That change
> would catch some but not all cases.

Of course, if you don't keep track of processes holding the lock (so you can
check whether they're still alive or not), there's basically no way to solve
it 100%.  It's the same old stateful vs stateless remote file system issue.
Maybe a nqnfs-like approach where locks have a limited lifetime (and
processes need to renew the lock if the lifetime turns out to be
insufficient, kind of like a watchdog) could solve it a bit better, tho it
probably would add complexity.

But it would be helpful to ensure that barring a `kill -9' or a network
failure (i.e. basically in case of a C-c), tla doesn't leave stale
locks around.

> That's why `lock-revision --break' exists, along with the carefully
> designed locking protocol:  so that although archives can wind up in
> a momentarily inconvenient state, they can't actually become wedged.

Which is obviously a very good thing.  An important property as well is that
a stale-lock-problem should either be auto-resolving (i.e. have some kind of
timeout) or should be resolvable by any user who bumps into it
(i.e. any user who needs to get the lock should have sufficient access
rights to break the stale lock).

Does tla's scheme ensures that we can't get into a situation where user
A holds the lock and user B can't break it because of access rights
preventing anybody but user A to get things back in order?

> The weird thing is, it's very, very, very common for newbies
> (presumably mostly coming from CVS) to assume that the condition
> solved by `lock-revision --break' is actually a wedged archive and to
> figure out for themselves how to fix it "by hand" on the server.

Maybe the error messages should mention `lock-revision --break'.


        Stefan