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

[John Arbash Meinel]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Martin Pool wrote:
...

> Yes, just printing a message that you failed to delete them and then
> leaving them there makes sense to me.
> 
> In a sense, this is actually more correct behaviour: Windows prohibits
> deletion of the files because they're still in use; therefore we
> should leave them on disk.  (In practice, you'd think that for most
> moderately small files the program would read them into memory and
> then no longer care whether they exist on disk, but maybe not.)
> 
> I think recent Windows releases do have some facility for
> automatically cleaning their temp directory.
> 
> Although the above is sufficient, there is another option: I think
> Windows has a 'delete on close' flag when creating files.  I don't
> know if this propagates properly when multiple processes open the
> file, and even if it does there may be a race when the external
> program's starting up.
> 

I think we could

1) Insert a small wait loop after the process goes away to see if it
releases the file. This will help fix transient things. We could try
every 100ms or so, for a max of 1s.

2) After waiting, just give up with a warning that we couldn't delete
the file.

3) We could try the delete-on-close (I think it is how some of the
TemporaryFile stuff works). I'm not sure what is exposed without having
to go to the win32 api directly, though. (Certainly TemporaryFile and
NamedTemporaryFile do *not* work for this stuff.) I also don't have any
good feeling for how process inheritance uses those files. If I were
guessing children that access them through the *same* file handle would
work, but the child process would need to know about it. (Sort of like
inheriting fileno 5 and telling the subprocess to just use that for input.)

I would make this very specific to windows + diff handling, rather than
do it for all files we want to delete. I suppose 1&2 aren't terrible for
generic, but I think we'll often have things open that won't be
released, like Visual Studio editing.

John
=:->
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Cygwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkoAvLYACgkQJdeBCYSNAAPlEwCfaCuZrC4zh1XXhba1a+iq2CQV
PqYAnRsctDiArN9UCscnpJpeDIN2ifcC
=WK52
-----END PGP SIGNATURE-----