<br><br><div class="gmail_quote">On Tue, May 5, 2009 at 7:42 AM, John Arbash Meinel <span dir="ltr"><<a href="mailto:john@arbash-meinel.com">john@arbash-meinel.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="im">-----BEGIN PGP SIGNED MESSAGE-----<br>
Hash: SHA1<br>
<br>
</div><div><div></div><div class="h5">Robert Collins wrote:<br>
> On Tue, 2009-05-05 at 13:54 +0900, Stephen J. Turnbull wrote:<br>
>> Is there any way to determine which program has the file open?<br>
><br>
> sysinternals has a tool similar to lsof; if its not a transient problem<br>
> you could use that. [Technically, walk the HANDLEs of all processes to<br>
> find those matching the file].<br>
><br>
> Also, NamedTemporary file is in since at least python2.4.<br>
><br>
> -Rob<br>
<br>
</div></div>Though there is a nice "feature" of win32 and NamedTemporaryFile, in<br>
that the file is opened exclusively by the single file handle you have<br>
right now.<br>
<br>
Put another way, no other process can open the named file, *nor* can the<br>
current process open it a second time.<br>
<br>
So I don't have any good idea what the "Named" portion is useful for on<br>
Win32, since it can't be used to actually *do* anything with the file.<br>
<br>
Note that this differs from the Linux usage, which is why we ran into<br>
some small problems with the btree overflow code on Windows, as it<br>
expected the current process could re-open the named file...<br>
<br>
So it exists, but it is pretty much useless, which is probably why we<br>
didn't use it.<br>
<br>
John<br>
=:-></blockquote><div><br>Aye! I see I have opened a rather large box of worms. Let me try to close it. :)<br><br>I am not sure how practical knowing the process holding things up would
be, anyway. It's usually pretty obvious. As Aaron points out, only
external diff/merge tools are affected and the user knows (we hope!)
when they are using those tools. Knowing which tool or resource is behaving badly
might invite sending a sighup but that really isn't very friendly and I
suspect it might not work on Windows anyway. So that seems like something bzr should not have to deal with.<br><br>The more I think about this, the more I think that a cure may be worse than the problem. So I am leaning toward (quoting myself yesterday):<br>
<br>Maritza Mendez wrote:<br><blockquote style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex; color: rgb(51, 51, 255);" class="gmail_quote"><i>So maybe the correct approach for diff (and merge) is to tolerate the
leftover temp files and print a friendly message saying that they were
left behind but allow execution to continue as if nothing went wrong. Since bzr does not need (and will not re-use) these files, there is no
real harm. The user has been advised and then it is up to him if to do
anything. Since bzr uses a well-known system temp folder, routine
maintenance should clean it out anyway.</i><br></blockquote><br>In other words, bzr would catch the exception, print a polite message about the external misbehavior, and just keep going. The only real difference between that and what happens now is that bzr would no longer pass an unhandled exception which causes users concern. I have not thought about how this change might affect external wrappers like tbzr...<br>
<br>-M<br><br></div></div><br>