RFR: 8005582 - java/lang/Runtime/exec/WinCommand.java intermittent test failures

[Stuart Marks]

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.

Hi Martin,

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 
deletion/retention.

> 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:

http://mail.openjdk.java.net/pipermail/core-libs-dev/2012-December/012761.html

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. :-)

s'marks