It's a Windows feature. We discovered this recently in debugging another
test failure. Windows is documented to do asynchronous deletes. You can't
depend on a file.delete() which returns true to have actually deleted the
file. It may be the case that another process has a file handle
Thanks all for the entertaining horror story - glad I no longer need to
fight with Windoze.
On 01/10/2013 12:59 AM, Stuart Marks wrote:
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
On 09/01/2013 19:46, Jim Gish wrote:
It's a Windows feature. We discovered this recently in debugging
another test failure. Windows is documented to do asynchronous
deletes. You can't depend on a file.delete() which returns true to
have actually deleted the file. It may be the case that
Would you be so kind as to push it, please?
Thanks,
Jim
On 01/10/2013 12:41 AM, Stuart Marks wrote:
On 1/9/13 10:49 AM, Jim Gish wrote:
Please review:
http://cr.openjdk.java.net/~jgish/Bug8005582-WinCommand-test-failures/
I have not yet been able to reproduce it, but now that I have a Windows
7 VM setup, I'm going to try. Windows sysinternals has a program called
handle.exe which I have used for years in determining who is holding
file handles. If we could install this on our test machines and invoke
it after
On 1/10/13 3:34 AM, Alan Bateman wrote:
On 09/01/2013 19:46, Jim Gish wrote:
It's a Windows feature. We discovered this recently in debugging another
test failure. Windows is documented to do asynchronous deletes. You can't
depend on a file.delete() which returns true to have actually
Please review:
http://cr.openjdk.java.net/~jgish/Bug8005582-WinCommand-test-failures/
http://cr.openjdk.java.net/%7Ejgish/Bug8005582-WinCommand-test-failures/
Summary: this test, when run on Windows, fails intermittently because
of asynchronous windows deletes. The test passes, deletes two
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
On 01/09/2013 02:33 PM, Martin Buchholz wrote:
On Wed, Jan 9, 2013 at 10:49 AM, Jim Gish jim.g...@oracle.com
mailto: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
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
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
On 1/9/13 5:26 PM, Martin Buchholz wrote:
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?
In other words, how
On 1/9/13 10:49 AM, Jim Gish wrote:
Please review:
http://cr.openjdk.java.net/~jgish/Bug8005582-WinCommand-test-failures/
http://cr.openjdk.java.net/%7Ejgish/Bug8005582-WinCommand-test-failures/
Summary: this test, when run on Windows, fails intermittently because of
asynchronous windows
14 matches
Mail list logo
