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

[Martin Buchholz]

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?

I'm not claiming to be a reviewer for this change.

On Wed, Jan 9, 2013 at 4:59 PM, Stuart Marks <stuart.marks at oracle.com>wrote:

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