John, I apologize for top-posting. I will insert notes in your email, below: <div class="gmail_quote">On Tue, Aug 17, 2010 at 11:31 AM, John Arbash Meinel <<a href="mailto:john@arbash-meinel.com">john@arbash-meinel.com</a>> wrote: <blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 <div class="im"> 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. > </div>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. </blockquote><div> 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? </div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"> Is 'D:' a mounted directory or is it a local disk? A mounted directory would be much more likely to experience a race condition. </blockquote><div> D: is a local disk. </div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"> 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. </blockquote><div> 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. </div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"> 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.) </blockquote><div> 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. </div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"> 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. </blockquote><div> 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. </div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"> 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.) </blockquote><div> 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 </div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"> John =:-> -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (Cygwin) Comment: Using GnuPG with Mozilla - <a href="http://enigmail.mozdev.org/" target="_blank">http://enigmail.mozdev.org/</a> iEYEARECAAYFAkxq1XgACgkQJdeBCYSNAANT0ACdEhpTHXQVQGndFxjcm0DVIihA 5JkAn2Dx+Ez/G8FhXGj2YqXM/NWaC/+g =n48+ -----END PGP SIGNATURE----- </blockquote></div>