UserWarning: lock on ... .bzr/checkout/dirstate ... not released
| Affects | Status | Importance | Assigned to | Milestone | |
|---|---|---|---|---|---|
| Bazaar |
Confirmed
|
Medium
|
Unassigned | ||
Bug Description
While doing a "bzr pull" on the same branch in another terminal:
andrew@
bzr: ERROR: Could not acquire lock [Errno 11] Resource temporarily unavailable
/usr/lib/
warn("lock on %r not released" % self.f)
This is a bzr-svn branch, in dirstate-
This isn't the normal way lock contention is reported to the user, particularly the UserWarning, but also it doesn't say "lock busy, retrying" or whatever it usually says. That way is clearer and friendlier to the user, and is what should happen here (or ideally no lock contention at all, but when there is it should be reported better).
I can also reproduce this with bzr.dev.
| John A Meinel (jameinel) wrote | #1 |
| Changed in bzr: | |
| importance: | Undecided → Medium |
| status: | New → Confirmed |
There are 2 bugs here:
1) If we fail to take a lock, we shouldn't think that the lock is held and not unlocked. Apparently we are creating a ReadLock object which is failing to actually acquire the lock, but it still thinks that unlock should be called. That would remove the "UserWarning".
2) The fancy "letting you know it is locked" code is part of LockDir, and not part of our OS-level locks. And it happens that LockDir doesn't do anything for read locks, and so the code is falling down to the DirState lock which is an OS lock.
We *could* introduce timeouts into the OS locks. I think all of the bugs/difficulty/etc surrounding it is a strong indication that we should try to avoid them entirely, though. (One bug is that you can't use dirstate trees on NFS unless the NFS server has locking enabled, etc).
So rather than directly fixing (2), we might opt for a new format that doesn't use them. (1) should still be fixed, though.