empty limbo dirs cause error about left-over files

OK, there is 3 empty directories in .bzr/checkout:

empty limbo dir, empty pending-deletion dir, and empty shelf dir.

Removing only limbo does not help. Removing pending-deletion does help.

But in this case there is actually third bug:

3) Error message tell me about limbo dir, but actual problem was in pending-deletion dir.

I think there is should be some command to remove all this limbo* junk from .bzr/checkout/

Right, limbo and pending_deletion are twins and should always be deleted together (IME).

But the bug is that you shouldn't ends up in that situation.
'bzr pull' is not supposed to left you in such a state, so if you can identify the faulty operation,
we can fix it.

If instead, you end up here while developing, say, a new to way to pull :-)
then may be you should fix that here :)

This is a dup of Bug 354012, but I have marked that as a dup of this because there seems to be more info in this bug.

Vincent, my answers:

> Right, limbo and pending_deletion are twins and should always be deleted together (IME).

Is it documented somewhere? Does this tip present in online help?
I was not aware of this.

> But the bug is that you shouldn't ends up in that situation.

But I am. And I don't know why.

> 'bzr pull' is not supposed to left you in such a state, so if you can identify the faulty operation,
we can fix it.

I don't know. I've not touched my qbzr mirror on that machine several days. As I see there was shelf. Maybe it's leftover after unshelve. I really don't know.

> If instead, you end up here while developing, say, a new to way to pull :-)
> then may be you should fix that here :)

No, it's just plain pull without any changes. Honestly.

This is easy to reproduce.

Steps to reproduce: in a branch that has some revisions:
cd .bzr/checkout
mkdir limbo
cd ../../
bzr pull . -r -2 --overwrite
bzr: ERROR: This tree contains left-over files from a failed operation.
    Please examine D:/test/.bzr/checkout/limbo to see if it contains
any files you wish to
    keep, and delete it when you are done.
rm .bzr/checkout/limbo -r
bzr pull . -r -2 --overwrite
Unable to obtain lock file:///D:/test/.bzr/branch/lock
held by <email address hidden> on host epsilon [process #2492]
locked 5 seconds ago
Will continue to try until 14:25:00, unless you press Ctrl-C
If you're sure that it's not being modified, use bzr break-lock
file:///D:/test/.bzr/branch/lock
bzr: interrupted

Here is the .bzr.log entry for the first bzr pull:

Fri 2009-09-11 14:19:54 +0200
0.079 bzr arguments: [u'pull', u'-r', u'-2', u'--overwrite']
0.094 looking for plugins in D:\My Documents\bzr-plugins
0.219 looking for plugins in C:/Program Files/Bazaar/plugins
0.219 Plugin name qbzr already loaded
0.266 encoding stdout as sys.stdout encoding 'cp437'
0.313 opening working tree 'D:/test'
0.438 Traceback (most recent call last):
  File "bzrlib\commands.pyo", line 835, in exception_to_return_code
  File "bzrlib\commands.pyo", line 1030, in run_bzr
  File "bzrlib\commands.pyo", line 647, in run_argv_aliases
  File "bzrlib\builtins.pyo", line 1022, in run
  File "bzrlib\decorators.pyo", line 192, in write_locked
  File "bzrlib\workingtree.pyo", line 1626, in pull
  File "bzrlib\merge.pyo", line 1536, in merge_inner
  File "bzrlib\merge.pyo", line 508, in do_merge
  File "bzrlib\merge.pyo", line 480, in _do_merge_to
  File "bzrlib\merge.pyo", line 616, in do_merge
  File "bzrlib\transform.pyo", line 1298, in __init__
ExistingLimbo: This tree contains left-over files from a failed operation.
    Please examine D:/test/.bzr/checkout/limbo to see if it contains
any files you wish to
    keep, and delete it when you are done.

0.438 return code 3

I think that the real bug is that the branch is left locked. This is
odd, because bzrlib.tests.test_transform.TestTreeTransform.test_existing_limbo
specifically checks that it is not left locked.

I trust you.

I don't think there is any documentation about the relationship between limbo and pending deletion, that is itself a bug.

Any hint in .bzr.log ?

I ended up in that situation more or less randomly months ago but I can't remember the details,
only that I was doing semi hackish things so I couldn't fully blame bzr and never reported the problems
(bad vila).

I think I have found the problem, and am preparing a patch.

vila wrote on irc:
> your example in #427773 is bogus, what we care about is how we end up with a limbo dir :)
> oh, right, there is a cascading bug too
> but let's search the root cause anyway, this should never happen and identify a real problem

Ok - I'm trying to fix the cascading bug (which I experienced when my computer experienced a power failure while it was doing a merge.)

Gary van der Merwe пишет:
> ** Changed in: bzr
> Status: Confirmed => Fix Committed
>
> ** Changed in: bzr
> Milestone: None => 2.1

Gary, if your fix is not API break, then I'd suggest to target it for
2.0.1 release. Because 2.1 will be release after 6 months.

Vincent, Aaron:

I know how to reproduce my problem.

1) make the change to some file and run bzr shelve.
2) on first prompt of shelve command kill the bzr (without Ctrl+C)
3) As result there is 3 empty dirs in checkout: limbo, pending-deletion, shelf

Because limbo and pending-deletion directories are both EMPTY -- I don't think bzr should blow up as it doing today. It can delete or reuse them. Today the check is VERY VERY hard: presence of any of this dirs even if they're empty -- and you get the problem.

Why?

I'd be ok with a clean fix for this in 2.0.1

On Tue, Sep 15, 2009 at 3:48 AM, Martin Pool <email address hidden> wrote:
> I'd be ok with a clean fix for this in 2.0.1

https://code.launchpad.net/~garyvdm/bzr/427773-2.0-unlock-when-limbo/+merge/11631

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

Alexander Belchenko wrote:
> Because limbo and pending-deletion directories are both EMPTY -- I don't
> think bzr should blow up as it doing today. It can delete or reuse them.
> Today the check is VERY VERY hard: presence of any of this dirs even if
> they're empty -- and you get the problem.
>
> Why?

Because the directories shouldn't be there at all. If you kill shelve
after you've shelved some changes, then the directories will be present
and have contents. Being present and empty is just a special case of
them being present.

Special handling makes bzr's behaviour less predictable, and I don't
think it should be done for rare failure modes.

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

iEYEARECAAYFAkrKSHAACgkQ0F+nu1YWqI0vAQCfZJD3oVDmlu7XF2hjrnLwNk/8
3loAn1XiQQ4R+JoAVfftoMPvjoZC7Ang
=U9p6
-----END PGP SIGNATURE-----

I encountered limbo related errors more than a few times.

All the situations I can remember were with *both* directories empty.
I deleted them and went my way.

It sounds perfectly safe to either delete them or, more simply. less risky, reuse them.
The failure mode is not rare and easy to recognize (both dirs empty), the risk is nil, we should fix that.

der| reports this is still happening in 2.1.0b3

der|: the limbo and pending-deletion are empty correct
der|: poolie, maybe this helps: I was workign with a Photoshop PSD file, and I was trying to revert it with: bzr revert --no-backup -r5 home.psd, after that the limbo and the pending-deletion directories were conflicting

bzr 2.1.0b3 on a Windows 7 system.

I was workign with a Photoshop PSD file, and I was trying to revert it with the following command:

bzr revert --no-backup -r5 home.psd

After that, bzr states the following:
bzr: ERROR: This tree contains left-over files from a failed operation.
    Please examine C:/Users/ernie/Desktop/gateway/.bzr/checkout/limbo to see if it contains any files you wish to
    keep, and delete it when you are done.

The 'limbo' and 'pending-deletion' files are empty. Also, when trying to revert the PSD file, Photoshop was open.

Here's how to replicate the bug:

1- Create a file called home.psd with anything in it.
2- Save the file, then close Photoshop.
3- Open the file home.psd in Photoshop again.
4- Modify and Save the changes
5- execute the following command: bzr revert home.psd

After execution, the Error message is displayed. Something important though, the file is actually reverted but bzr displays the error message even when reverting the file. Maybe this error message shouldn't be displayed since it had successfully reverted the file.

2.0 is still broken. Sighted again today in 2.0.2 latest Karmic version.

The focus of this bug is a bit fuzzy, Gary's fix doesn't address accepting empty limbo and pending deletion dirs.

I think the discussion here have stated the problem and its fix quite clearly so I don't want to open a new bug for this.

Re-opening as deleting empty limbo and pending-deletion dirs hasn't been implemented yet.

Should we reopen the 2.0 task of this as well?

No.

I know Gary did fix something useful here, but I think this actual bug as described is not fixed in 2.0, and since that series is now ancient and this is not a critical bug it is not going to be fixed, so I'm going to clear this up.

Fixed in lp:bzr/2.4; will be fixed in trunk when that is merged up.