bzr should automatically break locks from dead processes on the local machine
| Affects | Status | Importance | Assigned to | Milestone | |
|---|---|---|---|---|---|
| Bazaar |
Confirmed
|
Medium
|
Unassigned | ||
Bug Description
I had a "bzr checkout" running when a Windows vm crashed. When I started the vm up again, re-running the "bzr checkout" command resulted in this message about locks:
Unable to obtain lock file://
held by exarkun@
locked 49 hours, 46 minutes ago
Will continue to try until 15:02:16, unless you press Ctrl-C.
See "bzr help break-lock" for more.
After manually breaking the lock in another console, it proceeded to fail this way:
bzr: ERROR: This tree contains left-over files from a failed operation.
Please examine C:/twistedbot/
keep, and delete it when you are done.
I'm not sure what the problem is with the latter part of this failure. However, for the former, I don't see why I should manually have to break the lock involved. The system has been rebooted since the lock was acquired. The process cannot possibly be running anymore. bzr should be able to "break" the lock itself.
| Robert Collins (lifeless) wrote Re: [Bug 588431] [NEW] bzr locks persist across reboots | #1 |
| Changed in bzr: | |
| status: | New → Confirmed |
| importance: | Undecided → Low |
| tags: | added: lockdir |
| Vincent Ladeuil (vila) wrote Re: bzr locks persist across reboots | #2 |
| summary: |
- bzr locks persist across reboots + bzr should automatically break locks from dead processes on the local + machine |
| Changed in bzr: | |
| importance: | Low → Medium |
| tags: | added: affects-twisted |
| Martin Packman (gz) wrote | #3 |
| tags: | added: check-for-breezy |
We use the persistent locks when accessing branch and repository
objects over FTP and SFTP, and we need, for correctness, to exclude
FTP and SFTP writers when you are doing a local operation: if they
didn't share locks, Bad Things would trivially happen.
Its because these locks are exposed in such a way that SFTP and FTP
access can take and release them that they persist.
I do agree that an automatic-break when:
- the lock was obtained by this machine
- the machine's uptime is less than the age of the lock
might be nice.