[MERGE] [BUG 363837] Catch _win32_delete_readonly failure to remove file or directory and try to recover

[Maritza Mendez]

On Tue, May 5, 2009 at 7:42 AM, John Arbash Meinel
<john at arbash-meinel.com>wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Robert Collins wrote:
> > On Tue, 2009-05-05 at 13:54 +0900, Stephen J. Turnbull wrote:
> >> Is there any way to determine which program has the file open?
> >
> > sysinternals has a tool similar to lsof; if its not a transient problem
> > you could use that. [Technically, walk the HANDLEs of all processes to
> > find those matching the file].
> >
> > Also, NamedTemporary file is in since at least python2.4.
> >
> > -Rob
>
> Though there is a nice "feature" of win32 and NamedTemporaryFile, in
> that the file is opened exclusively by the single file handle you have
> right now.
>
> Put another way, no other process can open the named file, *nor* can the
> current process open it a second time.
>
> So I don't have any good idea what the "Named" portion is useful for on
> Win32, since it can't be used to actually *do* anything with the file.
>
> Note that this differs from the Linux usage, which is why we ran into
> some small problems with the btree overflow code on Windows, as it
> expected the current process could re-open the named file...
>
> So it exists, but it is pretty much useless, which is probably why we
> didn't use it.
>
> John
> =:->


Aye!  I see I have opened a rather large box of worms.   Let me try to close
it.  :)

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.

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):

Maritza Mendez wrote:

> *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.*
>

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...

-M
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.ubuntu.com/archives/bazaar/attachments/20090505/8db788ce/attachment-0001.htm