Chris,
Would it be useful to add some instrumentation/logging (to System.err)
if it's taking
more than one iteration to delete a file? We could end up with degraded
test performance if there is a general problem deleting files, and
otherwise would have
no way of understanding what the problem is (eg. up to 7.5 seconds are
allowed to delete the file)
Also, just curious what is the value in throwing InterruptedException
out of the delete() method?
It seems onerous for calling code to have to catch it.
Michael
On 07/11/13 10:05, Chris Hegarty wrote:
Virus checkers and, on more modern Windows OSes, Windows Experience
Service, and other external processes, have been causing trouble when
it comes to tests deleting files.
On a number of occasions in the past retry logic has been added to
tests that need to delete files. Also, the jtreg harness has similar
logic when cleaning up temporary files.
This has reared its head again with:
8027902: TEST_BUG: java/net/URLClassLoader/closetest/CloseTest.java
and java/net/URLClassLoader/closetest/GetResourceAsStream.java failed
due to dir operation failed.
8022213: Intermittent test failures in java/net/URLClassLoader
I'd like to add file utility functions to the common jdk/testlibrary,
starting with a "more reliable" delete. I've made minimal changes to
the URLClassloader tests to use this ( more could be done, but this is
just a start ).
http://cr.openjdk.java.net/~chegar/fileUtils/webrev/
The important part here for review is the "API" and impl in FileUtils.
Thanks,
-Chris.
