Branch generates ImmortalLimbo warning ?

[Maritza Mendez]

John,  I apologize for top-posting.  I will insert notes in your email,
below:

On Tue, Aug 17, 2010 at 11:31 AM, John Arbash Meinel <john at arbash-meinel.com
> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Maritza Mendez wrote:
> >
> > I am running bzr 2.2 packaged with bzr-explorer for Windows with the
> > same "big" project I've described here before.
> >
> > I have a shared repo at D:/VCS/bzrEval with main branch
> > D:/VCS/bzrEval/trunk and I branch to D:/VCS/bzrEval/dev_d within the
> > shared repo and I get the following message in .bzr.log (and in the
> > bzr-explorer GUI):
> >
> > ImmortalLimbo: Unable to delete transform temporary directory
> > D:/VCS/bzrEval/dev_d/.bzr/checkout/limbo.
> >     Please examine D:/VCS/bzrEval/dev_d/.bzr/checkout/limbo to see if it
> > contains any files you wish to
> >     keep, and delete it when you are done.
> >
> > [Traceback is attached]
> >
> > It turns out that the limbo directory is empty.  But what would I have
> > done if it had files in it?  I need to understand this well enough to be
> > able to explain it to people who are just trying to get their (non-bzr)
> > jobs done.
> >
>
> I have a strong suspicion you have a filesystem race condition, though I
> don't know *why*. Specifically, if you run bzr, get this error, and then
> look and find the directory empty, I would guess that for a brief moment
> after we issued a rename command, it didn't actually take affect before
> we issued the 'rmdir' command.
>
>
I did browse (with Windows Explorer) the limbo directories during the branch
operation.  There were seven  directories matching the pattern new-\d.  I
did not open any files.  I only opened directories and saw the catalogs.
After the branch operation completed (with the Limbo message), the limbo
directory was empty.  Perhaps I created a race condition simply by having
the directory catalogs open for reading?


> Is 'D:' a mounted directory or is it a local disk? A mounted directory
> would be much more likely to experience a race condition.
>
>
D: is a local disk.


> If you really do have a race, one option internally is to just add a
> polling loop around the rmdir. So we try to delete it, get not-empty,
> wait a tick or two, then try again.
>
>
Yeah.  I suspect you like that as much I do.  I admit I have written code
like that for Windows.  I'm not proud of it.


> I don't know if you are comfortable running bzr from source rather than
> from the installed copy. If you are, then we can pretty easily work up
> some patches that would at least make debugging this easier. (When we
> get a rmdir failure, just listdir() the directory, to see what is there.
> If *that* comes up empty, then your system is lying to us for some reason.)
>
>
Sure.  I use to run bzr from source all the time, until you guys started
getting good at packaging it.  :)  :)

I would be happy to try that out, but since my attempts to reproduce the
observation have so far failed, I suggest that we hold off until I can
reproduce it at least one-in-five times.


> Another possibility is some sort of race condition with Virus Scanners.
> They may lock a directory while they are looking at newly created
> content, and then after we've moved all the content out, they haven't
> stopped searching that dir. (as an example.) Though honestly, I would
> expect that to cause problems moving files out of the directory, rather
> than problems deleting the directory.
>
>
I agree.  I think we'd have a lot of problems with bzr (and other tools) if
our virus scanner were getting in the way.


>
> And one further option. Switch to using lightweight checkouts and
> treeless branches. You'll likely be better served by this in the long
> run (since we don't have to recreate the whole tree content, just the
> few files which are actually different). But some of it will depend on
> your specific needs. (And yes, it doesn't solve the problem if you still
> experience the limbo issue on the first checkout.)
>
>
We've been avoiding lightweight checkouts, because we have times of day when
our internal network is saturated anyway, which makes any operations which
need the network problematic.  I know that's our problem and bzr can't do
anything about it, but that's why we favor full branches.

Thanks, and i will try to reproduce the observation a few more times today
and report back.

~M



>
> John
> =:->
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.9 (Cygwin)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>
> iEYEARECAAYFAkxq1XgACgkQJdeBCYSNAANT0ACdEhpTHXQVQGndFxjcm0DVIihA
> 5JkAn2Dx+Ez/G8FhXGj2YqXM/NWaC/+g
> =n48+
> -----END PGP SIGNATURE-----
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.ubuntu.com/archives/bazaar/attachments/20100817/204ed568/attachment-0001.htm