bzr break-lock does not hint who is holding the lock

[Adi Roiban]

It looks like in some cases, bzr break-lock does not provide hints about how a lock can be removed.

This is the output of my commands:

$ bzr ci -m"something"
bzr: ERROR: Could not acquire lock "/home/adi/launchpad/lp-branches/bug-509252-take-2/.bzr/checkout/dirstate": (11, 'Resource temporarily unavailable')

$ bzr break-lock
bzr: ERROR: The lock for '/home/adi/launchpad/lp-branches/bug-509252-take-2' is in use and cannot be broken.

$ bzr -Derror break-lock
bzr: ERROR: bzrlib.errors.LockActive: The lock for '/home/adi/launchpad/lp-branches/bug-509252-take-2' is in use and cannot be broken.

Traceback (most recent call last):
  File "/usr/lib/python2.6/dist-packages/bzrlib/commands.py", line 842, in exception_to_return_code
    return the_callable(*args, **kwargs)
  File "/usr/lib/python2.6/dist-packages/bzrlib/commands.py", line 1037, in run_bzr
    ret = run(*run_argv)
  File "/usr/lib/python2.6/dist-packages/bzrlib/commands.py", line 654, in run_argv_aliases
    return self.run(**all_cmd_args)
  File "/usr/lib/python2.6/dist-packages/bzrlib/builtins.py", line 4692, in run
    control.break_lock()
  File "/usr/lib/python2.6/dist-packages/bzrlib/bzrdir.py", line 125, in break_lock
    thing_to_unlock.break_lock()
  File "/usr/lib/python2.6/dist-packages/bzrlib/workingtree_4.py", line 174, in break_lock
    raise errors.LockActive(self.basedir)
LockActive: The lock for '/home/adi/launchpad/lp-branches/bug-509252-take-2' is in use and cannot be broken.

$ lsof | grep bug-509252-take-2
gedit 7562 adi 52rR REG 8,5 2118222 2689075 /home/adi/launchpad/lp-branches/bug-509252-take-2/.bzr/checkout/dirstate

[Martin Pool (mbp)]

The problem here is with the OS lock on the working directory.
Unfortunately we can't break them and there is no portable way to find
out who's holding it, so this is basically another consequence of bug
98836.
--
Martin <http://launchpad.net/~mbp/>

[John A Meinel (jameinel)]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Martin Pool wrote:
> *** This bug is a duplicate of bug 98836 ***
> https://bugs.launchpad.net/bugs/98836
>
> The problem here is with the OS lock on the working directory.
> Unfortunately we can't break them and there is no portable way to find
> out who's holding it, so this is basically another consequence of bug
> 98836.

It is, but we generally only hold the OS lock when we also hold the WT
disk lock. So we could check that first/if the other appears lock.

I could be wrong, but I think we check the OS lock before we check the
disk lock.

John
=:->

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Cygwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkt8kHUACgkQJdeBCYSNAAPnsACglBXTcgnUBCv41MfHg/ZUBaM0
cjwAnAzHL4Omj+zXND9Dbt4OoTYL94ZF
=++e8
-----END PGP SIGNATURE-----

[Martin Pool (mbp)]

On 18 February 2010 11:57, John A Meinel <email address hidden> wrote:
> It is, but we generally only hold the OS lock when we also hold the WT
> disk lock. So we could check that first/if the other appears lock.
>
> I could be wrong, but I think we check the OS lock before we check the
> disk lock.

Right, so I think you'll only see this problem if the lock is held by
a reader, in which case there is no OS lock. imbw.

--
Martin <http://launchpad.net/~mbp/>