Merge lp:~spiv/bzr/graceful-broken-lockdir-619872-2.0 into lp:bzr/2.0
Status: | Merged |
---|---|
Approved by: | Martin Pool |
Approved revision: | no longer in the source branch. |
Merged at revision: | 4757 |
Proposed branch: | lp:~spiv/bzr/graceful-broken-lockdir-619872-2.0 |
Merge into: | lp:bzr/2.0 |
Diff against target: |
256 lines (+172/-2) 5 files modified
bzrlib/errors.py (+12/-0) bzrlib/lockdir.py (+44/-2) bzrlib/tests/test_errors.py (+7/-0) bzrlib/tests/test_lockdir.py (+101/-0) bzrlib/tests/test_rio.py (+8/-0) |
To merge this branch: | bzr merge lp:~spiv/bzr/graceful-broken-lockdir-619872-2.0 |
Related bugs: |
Reviewer | Review Type | Date Requested | Status |
---|---|---|---|
Martin Pool | Approve | ||
Review via email: mp+34657@code.launchpad.net |
Commit message
more gracefully handle corrupt lockdirs (missing/null held files)
Description of the change
This patch addresses bug 619872. It adds a LockCorrupt error so that the
lockdir code can clearly distinguish apparently-
other conditions like not-held. Specifically this deals with the case where the
info file is present, but unparseable, e.g. contains only NUL bytes. This
immediately improves the error reporting to the user when a corrupt
lock/held/info file is encountered (avoids a traceback, and suggests the user
try 'bzr break-lock').
Further, it improves break_lock to cope gracefully with LockCorrupt, so that it
will prompt “Break (corrupt $lock_repr)” [similar to the usual “Break
($lock_info)”], and successfully clears the corrupt lock.
I've added quite a few tests to try make sure we're covering all the interesting
cases. Ideally any time there is a held/ directory in a LockDir without a
parseable info file we'd raise LockCorrupt, but actually there are many cases
already where we silently treat an empty held/ directory as the same as an
unheld lock:
* many places assume NoSuchFile when reading held/info implies there is no lock
* attempt_lock assumes that if rename(new-dir, 'held') raises no error, then
there was no lock, but on POSIX rename(new-dir, empty-dir) silently passes
[but not on Windows, IIUC, so it would raise LockContention there... but
wait_lock would then try to peek after the timeout and get LockCorrupt!]
I don't think we can fix these cases without possibly impacting performance, and
arguably at least some of these cases are harmless, so I've left this behaviour
untouched, although I've explicitly allowed some tests to tolerate LockCorrupt
if a future implementation chooses to notice these issues. Most importantly at
least there are now tests that we don't explode in these cases.
I've written this patch against 2.0.x, although perhaps this is a bit too much
like a new feature to belong on the stable branch. (Certainly if we had
translations this patch would violate Ubuntu's SRU policy by introducing new
strings.) I haven't yet written the NEWS entries for this patch, but if we
decide it is ok for 2.0 I certainly will!
That looks good.
I do wonder how we end up with lock files containing nulls.
I think the LoggingUIFactory should be moved into somewhere more generally reusable, and definitely not copy&pasted.
The error could have a link to the bug reporting the kind of corruption we saw.