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

[Stephen J. Turnbull]

Maritza Mendez writes:

 > > I think you are making the case that win32's inability to delete an open
 > > file is a bug which we should try to work around.  I think that's fair,
 > > but your solution is not a very general solution.  It's only a solution
 > > if you have reason to believe that the program holding the file open
 > > will release it very soon.
 > >
 > > I can think of only two cases where that is likely:
 > > 1. The program holding the file open is known to have been closed
 > >   recently
 > > 2. The program holding the file open is a scanner of some kind that hold
 > >   the file open briefly.
 > 
 > 
 > I agree.  And although I believe that one of these is "almost always" the
 > truth, you are correct to expose my hidden assumption.  I find I have no
 > good answer for this in general.

It may be "almost always" the case in CPU cycles, but the contrary is
common enough to be really annoying to the user.  I know I "almost
always" get caught with something open when I'm removing a USB key!

 > > A very common case will be that the user has the file open in another
 > > program, and in that case, the most productive path may be to request
 > > that the user close the file.

I'd really like to deny that (my own workflow is conditioned by Emacs,
which closes files once it has read their contents into buffers, so I
often "save and forget" a file, but keep the buffer around for later
reference "just in case"), but unfortunately I can't think of an
alternative.

Is there any way to determine which program has the file open?

[[ For my personal education:

 > Aha!  I understand now.  I am not in love with bare raise, but I
 > agree it is much better than bare except!

What's not to love?  Of course bare raise can be misused, but if the
low-level routine can do some routine-specific cleanup that the caller
doesn't want to know about, then re-raise to let the caller handle the
exception semantically, isn't that precisely what you asked for? ]]

 > > It also means that diff and merge will deal with a low-level problem
 > > which so far has been seen only on Windows.
 > 
 > > Since this solution mostly applies to temp directories used as input for
 > > external programs, perhaps it could be provided as a class:
 > > osutils.TempDir or something like that.

Have you looked at how Python 3 addresses this stuff?  os.tempnam is
gone (unfortunately 2to3 doesn't catch that yet!), and there are new
functions such as tempfile.NamedTemporaryFile() that use mkstemp().
Perhaps the implementation can be backported to 2.x?