shelve fails on win32 with "Could not acquire lock"

[James Teh]

I am running bzr.dev revision 3878 on Cygwin. When I try to use the in-built shelve command, I receive the following error:
bzr: ERROR: Could not acquire lock "[Errno 13] Permission denied"

Relevant log info follows:
0.459 opening working tree '/home/jamie/a'
0.499 Traceback (most recent call last):
  File "/usr/lib/python2.5/site-packages/bzrlib/commands.py", line 893, in run_bzr_catch_errors
    return run_bzr(argv)
  File "/usr/lib/python2.5/site-packages/bzrlib/commands.py", line 839, in run_bzr
    ret = run(*run_argv)
  File "/usr/lib/python2.5/site-packages/bzrlib/commands.py", line 539, in run_argv_aliases
    return self.run(**all_cmd_args)
  File "/usr/lib/python2.5/site-packages/bzrlib/builtins.py", line 4774, in run
    message).run()
  File "/usr/lib/python2.5/site-packages/bzrlib/shelf_ui.py", line 84, in run
    self.file_list)
  File "/usr/lib/python2.5/site-packages/bzrlib/shelf.py", line 47, in __init__
    self.shelf_transform = transform.TransformPreview(self.target_tree)
  File "/usr/lib/python2.5/site-packages/bzrlib/transform.py", line 1516, in __init__
    tree.lock_read()
  File "/usr/lib/python2.5/site-packages/bzrlib/workingtree_4.py", line 1727, in lock_read
    self._dirstate.lock_read()
  File "/usr/lib/python2.5/site-packages/bzrlib/dirstate.py", line 2724, in lock_read
    self._lock_token = lock.ReadLock(self._filename)
  File "/usr/lib/python2.5/site-packages/bzrlib/lock.py", line 212, in __init__
    raise errors.LockContention(e)
LockContention: Could not acquire lock "[Errno 13] Permission denied"

0.499 return code 3

I believe this is the same bug discussed for the native Win32 version in this mailing list thread:
http://www.nabble.com/Shelf-bug---td20373559.html
Some solutions were proposed therein, but there doesn't seem to have been any further progress.

[Alexander Belchenko (bialix)]

OS locks again! Confirmed on native Windows -- the same error. shelve is unusable on Windows. bzr 1.10.

[Henrik Steensland (henrik-steensland)]

Why is this not fixed in 1.11?
Not only does the command "bzr shelve" always fail on Windows, it is also complicated to recover from. See below.

> bzr version
Bazaar (bzr) 1.11
  Python interpreter: C:\Program\Bazaar\python25.dll 2.5.2
  Python standard library: C:\Program\Bazaar\lib\library.zip
  bzrlib: C:\Program\Bazaar\lib\library.zip\bzrlib

> bzr shelve
bzr: ERROR: Could not acquire lock "C:/src/.bzr/checkout/dirstate"

> bzr commit
Unable to obtain lock file:///C:/src/.bzr/checkout/lock
held by <email address hidden> on host lime [process #5416]
locked 33 seconds ago
Will continue to try until 09:57:09, unless you press Ctrl-C
If you're sure that it's not being modified, use bzr break-lock file:///C:/src/.bzr/checkout/lock
bzr: ERROR: Could not acquire lock "LockDir(file:///C:/src/.bzr/checkout/lock)"

> bzr break-lock .bzr\checkout\lock
Break lock file:///C:/src/.bzr/checkout/lock
held by <email address hidden> on host lime [process #5416]
locked 8 minutes, 3 seconds ago? [y/n]: y

> bzr shelve
bzr: ERROR: This tree contains left-over files from a failed operation.
    Please examine C:/src/.bzr/checkout/limbo to see if it contains any files you wish to keep, and delete it when you are done.

> rmdir /sq .bzr\checkout\limbo

> bzr shelve
bzr: ERROR: This tree contains left-over files from a failed operation.
    Please examine C:/src/.bzr/checkout/pending-deletion to see if it contains any files you wish to keep, and delete it when you are done.

> rmdir /sq .bzr\checkout\pending-deletion

> bzr shelve
bzr: ERROR: This tree contains left-over files from a failed operation.
    Please examine C:/src/.bzr/checkout/limbo to see if it contains any files you wish to keep, and delete it when you are done.

Again!?

> rmdir /sq .bzr\checkout\limbo

Now, we are finally back to square one.

[Alexander Belchenko (bialix)]

Henrik Steensland пишет:
> Why is this not fixed in 1.11?

Good question. I think I know the answer. :-/

In the meantime you still can use shelve1 and unshelve1 instead of shelve/unshelve.

[Henrik Steensland (henrik-steensland)]

Thank you for your answer
But it feels like I am missing something here?

> bzr shelve1
--- Viewer/Panel.cpp 2009-01-22 13:33:39 +0000
+++ Viewer/Panel.cpp 2009-01-23 09:05:33 +0000
@@ -514,4 +514,5 @@
some
lines
of code
+
 }
\ No newline at end of file
Shelve this change? (1 of 1) [yndisq?] (y): y

Status:
  Viewer/Panel.cpp 2009-01-22 13:33:39 +0000
   1 hunks to be shelved
   0 hunks to be kept

Shelve these changes? [yrsiq?] (y): y
Shelving to default/01: "Changes shelved on 2009-01-23 10:44:21"
bzr: ERROR: Error invoking patch: No such file or directory

[Henrik Steensland (henrik-steensland)]

Update:
Since it seemed that "bzr shelve1" used "patch" rather than some variant of "bzr patch" I installed gnu patch for windows from http://gnuwin32.sourceforge.net/packages/patch.htm

After that, at least I can use shelve1 and also, as a bonus, commit -i from plugins/interactive.

Shouldn't bzr for windows bundle the gnu pathc program in the installer if it's needed for these commands to work?
Please move my comment to an appropriate thread if such a thread exists.

[Alexander Belchenko (bialix)]

Henrik Steensland пишет:
> Thank you for your answer
> But it feels like I am missing something here?
>
>> bzr shelve1
> --- Viewer/Panel.cpp 2009-01-22 13:33:39 +0000
> +++ Viewer/Panel.cpp 2009-01-23 09:05:33 +0000
> @@ -514,4 +514,5 @@
> some
> lines
> of code
> +
> }
> \ No newline at end of file
> Shelve this change? (1 of 1) [yndisq?] (y): y
>
> Status:
> Viewer/Panel.cpp 2009-01-22 13:33:39 +0000
> 1 hunks to be shelved
> 0 hunks to be kept
>
> Shelve these changes? [yrsiq?] (y): y
> Shelving to default/01: "Changes shelved on 2009-01-23 10:44:21"
> bzr: ERROR: Error invoking patch: No such file or directory

Yep, perhaps you need to install GNU patch utility, e.g. from
http://gnuwin32.sourceforge.net/packages/patch.htm

and then ensure path to the utility binary added to your PATH environment
variable (typically it will be installed to C:\Program Files\GnuWin32
then you need to add C:\Program Files\GnuWin32\bin to the PATH).

[Alexander Belchenko (bialix)]

Henrik Steensland пишет:
> Update:
> Since it seemed that "bzr shelve1" used "patch" rather than some variant of "bzr patch" I installed gnu patch for windows from http://gnuwin32.sourceforge.net/packages/patch.htm
>
> After that, at least I can use shelve1 and also, as a bonus, commit -i
> from plugins/interactive.
>
> Shouldn't bzr for windows bundle the gnu pathc program in the installer if it's needed for these commands to work?
> Please move my comment to an appropriate thread if such a thread exists.
>

You'd better send this question to main bzr mailing list.
Bundle GNU patch into official installer make very big sense for me,
because now bzrtools is bundled too.

[John A Meinel (jameinel)]

See associated branch, which changes how the lifetime of various locks are mantained

[Alexander Belchenko (bialix)]

John, does your branch fixes https://bugs.launchpad.net/bzr/+bug/206406 as well?

[John A Meinel (jameinel)]

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

Alexander Belchenko wrote:
> John, does your branch fixes https://bugs.launchpad.net/bzr/+bug/206406
> as well?
>

Yes (tested manually)

John
=:->

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

iEYEARECAAYFAkl7xU8ACgkQJdeBCYSNAAMntgCaAwrqbjH+yBU5vXSxubVqBZPu
gL4An3L3/2bIosr0ZfdxcBoKoqI6DflD
=YtC7
-----END PGP SIGNATURE-----

[Alexander Belchenko (bialix)]

John A Meinel пишет:
> Alexander Belchenko wrote:
>> John, does your branch fixes https://bugs.launchpad.net/bzr/+bug/206406
>> as well?
>
>
> Yes (tested manually)

Great!

[James Teh (jteh)]

This branch works very well for me. Thanks!

I notice this is not in bzr 1.12rc1. Is this going to make it into 1.12? If not, any particular reason? shelve is completely unuseable on Windows without it.

[Radim Kolář (hsn10)]

You are right. I tested it on windows too and this bug is still not fixed in 1.12rc1.

[John A Meinel (jameinel)]

It will not be in 1.12 because while it fixes shelve it breaks things like 'diff' in various edge cases (bzr diff --old XXX --new YYY).

I'm trying to finish tracking down all the places that need some updating, so hopefully we will have all of it working in 1.13.

In the meantime, you can use "bzr [un]shelve1" from bzrtools (if you have a 'patch.exe' in your PATH).

[Dorin Scutarașu (dorins)]

This is still not fixed in 1.13.1 .

Thank's for the "bzr [un]shelve1' workaround though.

[Piotr Kalinowski (pitkali)]

I would like to bring to general attention the fact, that I am still able to reproduce this bug in bzr 1.14.1. Tell me, is it really that difficult to fix? Shouldn't the status be changed to reflect that or something?

[Martin Pool (mbp)]

I don't know how hard it is to finish fixing it, but I've reopened the bug.

[Adrian Wilkins (adrian-wilkins)]

Is this linked to the same error occuring during a push of a new branch (local filesystem with tree)? The push completes successfully, but you get a

159# bzr push d:\bzr\test\one --create-prefix
bzr: ERROR: Could not acquire lock "D:/bzr/test/one/.bzr/checkout/dirstate":
160# bzr push d:\bzr\test\one --create-prefix
No new revisions to push.
161#

[Alexander Belchenko (bialix)]

Adrian Wilkins пишет:
> Is this linked to the same error occuring during a push of a new branch
> (local filesystem with tree)? The push completes successfully, but you
> get a

The root case is the same, yes. OS locks must die!

>
> 159# bzr push d:\bzr\test\one --create-prefix
> bzr: ERROR: Could not acquire lock "D:/bzr/test/one/.bzr/checkout/dirstate":
> 160# bzr push d:\bzr\test\one --create-prefix
> No new revisions to push.
> 161#
>

[Martitza (martitzam)]

So what does it take to kill os locks? Is there any way for non core developers to help? It sounds like a scary architectural change.

-M

[Adrian Wilkins (adrian-wilkins)]

> In the meantime, you can use "bzr [un]shelve1" from bzrtools (if you have a 'patch.exe' in your PATH).

Note that on Vista (and presumably Win7), GNU patch will always trigger UAC simply because it's called "patch.exe".

You have to go through some shenanigans editing some of it's internal resources to contain a manifest that tells Vista not to freak out about it.

This page has some pointers where to go
http://stackoverflow.com/questions/533939/how-to-prevent-vista-from-requiring-elevation-on-patch-exe

Here's the SF bug about it (dr_barnowl is my scary alter-ego)
http://sourceforge.net/tracker/index.php?func=detail&aid=1890860&group_id=23617&atid=379173

[Robert Collins (lifeless)]

This *is* landed in trunk, but not in 2.0, and (as per mail to the list) we need to sort out how to represent and report on such items so we don't lose them.

Sorry about the bug-noise.

[Martin Pool (mbp)]

Maritza wrote:

> So what does it take to kill os locks? Is there any way for non core developers to help? It sounds like a scary architectural change.

It's not a big architectural change, but it is a nontrivial technical change. Probably the best thing to help would be to help criticize a spec when we start drafting one.

[Robert Collins (lifeless)]

 status fixreleased

(its in 2.0 and bzr.dev now)

[Alexander Belchenko (bialix)]

Martin Pool пишет:
> ** Also affects: bzr/1.18
> Importance: Undecided
> Status: New
>
> ** Changed in: bzr/1.18
> Status: New => Fix Released
>
> ** Changed in: bzr/1.18
> Importance: Undecided => Medium

Martin, this fix is not released as official 1.18, but present in
lp:bzr/1.18 branch. And it can be released as 1.18.1.

__________ Information from ESET NOD32 Antivirus, version of virus signature database 4401 (20090906) __________

The message was checked by ESET NOD32 Antivirus.

http://www.esetnod32.ru

[Martin Pool (mbp)]

2009/9/7 Alexander Belchenko <email address hidden>:
> Martin Pool пишет:
>> ** Also affects: bzr/1.18
>>    Importance: Undecided
>>        Status: New
>>
>> ** Changed in: bzr/1.18
>>        Status: New => Fix Released
>>
>> ** Changed in: bzr/1.18
>>    Importance: Undecided => Medium
>
> Martin, this fix is not released as official 1.18, but present in
> lp:bzr/1.18 branch. And it can be released as 1.18.1.

Right, 'fix released' in our convention means it's fixed in this
branch. See the recent list threads.

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