RFR: 8005582 - java/lang/Runtime/exec/WinCommand.java intermittent test failures
stuart.marks at oracle.com
Thu Jan 10 05:40:27 UTC 2013
On 1/9/13 5:26 PM, Martin Buchholz wrote:
> Well, if this is the behavior you can expect from Windows, carry on!
> But how can anyone get reliable behavior if a file delete can fail capriciously
> in two dimensions - it might be "in use" , or it might be an already deleted ghost?
In other words, how can anyone ever get any work done on Windows? That is an
excellent question, one for which I do not have the answer. :-)
I think the practical answer is that everybody puts up with it and tries to
come up with hacky workarounds. For example, the Mercurial developers have run
into this; see  and the links at the bottom of that page. They ended up with
a policy of first renaming the file to a random name, retrying 10 times if
necessary. Then they try to unlink. If at that point the unlink fails, they try
to remove the READONLY attribute and retry. If the unlink still fails, they
give up. See win32.unlink at line 344 in .
There is the inevitable stackoverflow page . They basically ended up with
something similar, renaming before deleting, although it's amusing that using
GetTempFileName() creates a uniquely named temp file, which must be deleted
before something can be renamed onto it, oh wait....
And then there is the rant at  which points the accusing finger at the
Windows Application Experience server (same as DeHaven in his analysis of the
Arrrghs fix), which also mentions the terrible consequences if you decide to
disable this service in a vain attempt to speed up your system.
I envision a task for someone in the near future of writing a
rename-to-random-filename-then-delete utility function in Java (similar to
Mercurial's win32.unlink) and converting the tests to use it. Maybe we should
consider changing File.delete() and Files.delete() to do this by default on
More information about the core-libs-dev