On 1/9/13 11:33 AM, Martin Buchholz wrote:
On Wed, Jan 9, 2013 at 10:49 AM, Jim Gish <jim.g...@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
