Exception when accessing locked archive.

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Create a new repo
2. Start some large writing operation, like importing a huge directory
3. Kill the boar process in some way that will not allow normal cleanup 
procedures (kill -9, or yank the drive)
4. Execute the same operation again (or any other writing operation)

What is the expected output? What do you see instead?

The operation should resume normally. Instead, the following exception is 
thrown:

Traceback (most recent call last):
  File "C:\Python26\boar\boar", line 584, in <module>
    return_code = main()
  File "C:\Python26\boar\boar", line 563, in main
    return cmd_clone(args[1:])
  File "C:\Python26\boar\boar", line 446, in cmd_clone
    repo2 = repository.Repo(repopath2)
  File "C:\Python26\boar\blobrepo\repository.py", line 117, in __init__
    self.repo_mutex.lock_with_timeout(60)
  File "C:\Python26\boar\common.py", line 317, in lock_with_timeout
    except MutexLocked:
NameError: global name 'MutexLocked' is not defined

A workaround is to make sure that no other process is accessing the repository, 
and then remove all the mutex-* files in the tmp directory in the repo.

Original issue reported on code.google.com by ekb...@gmail.com on 20 Jul 2011 at 8:46

[GoogleCodeExporter]

Actually, it is not in the general case possible to determine if the lock is 
active, or if the owning process has died. It is possible on a single computer 
of course, but if the repository is on a network share and the locking process 
is on another computer, there is no way to find out if the locking process is 
still alive.

Therefore, the goal of this issue should be to make sure there is a nice 
message explaining the problem, and telling the user how to resolve the problem 
manually if necessary.

Original comment by ekb...@gmail.com on 10 Aug 2011 at 2:48

[GoogleCodeExporter]

The process could write time-stamp to some file mutex-*/alive.txt at constant 
time interval T1 (e.g. 10 sec)

Another process can check this file. If it exceeds T1 or T1x2 (i.e >20sec) 
process is dead.

Original comment by BGA...@gmail.com on 26 Feb 2013 at 12:41