RFR: 8005582 - java/lang/Runtime/exec/WinCommand.java intermittent test failures
stuart.marks at oracle.com
Thu Jan 10 00:59:53 UTC 2013
On 1/9/13 11:33 AM, Martin Buchholz wrote:
> On Wed, Jan 9, 2013 at 10:49 AM, Jim Gish <jim.gish at oracle.com> wrote:
>> I'm in the process of adding deletion retry behavior to jtreg, but in the
>> meantime we think it makes sense to provide a more stable test environment
>> by simply getting rid of the redundant deletes by the test itself. There
>> really is no need for tests to delete files from the scratch directory at
>> the end of a test because jtreg carries a guarantee of cleanup.
> I consider it good practice for a test to delete temporary files - it's
> just a java program that might be run outside of the test harness.
In general it indeed is a good practice for things to clean up after
themselves, but there are several different considerations.
I was talking about this issue with Jon Gibbons, and he mentioned that it's
often a good idea for tests to leave around files for diagnostic purposes, in
case they fail, or in case they succeed unexpectedly. Tests cleaning up after
themselves potentially destroys that information. That's why jtreg has the
-retain option, that controls when (beginning of next test run, end of this
test run), and under what circumstances (success, failure, error) the test's
scratch files are removed.
We're also moving toward an environment where we're running the test suite much
more intensively than before, on all the platforms. Thus the tests are being
run from jtreg very frequently, and while it's convenient for them to be
invoked as standalone programs (outside the test harness) this is becoming
relatively rare. Having options in the test to support the latter case is fine,
but I think that running tests from jtreg needs to be considered the default
case, and thus modify things to allow jtreg to determine the policy for file
> Perhaps there's a deeper problem - why does the file system present
> inconsistent views? Is it a Windows bug?
Jim answered this already, but I wanted to add that we've run into this problem
before. See here for example:
This is with the Arrrghs test (which I'm sure you're familiar with). I guess
it's a question of whether the file system is behaving inconsistently. From a
Unix point of view asynchronous deletes are inconsistent, but on Windows this
is apparently perfectly normal behavior. :-)
More information about the core-libs-dev