RFR: JDK-8028628 - java/nio/channels/FileChannel/Size.java failed once in the same binary run

Chris Hegarty chris.hegarty at oracle.com
Wed Nov 20 11:29:52 UTC 2013

On 20/11/13 05:00, Mandy Chung wrote:
> Thanks for the details Dan [1].  It is useful.   The reason why I was
> wondering the difference with temp dir is that the test workdir might be
> excluded from the anti-virus scanner on that test machine. Now you have
> explained it.

Right, this would be my preference too. There is more control if tests 
write to the current working directory.

The changes look fine to me, but there is still a ' blah.delete();' on 
L63 of the new file. I think this should use 
FileUtils.deleteFileWithRetry() [1], as it could still fail, right?



> thanks
> Mandy
> [1]
> http://mail.openjdk.java.net/pipermail/net-dev/2013-November/007783.html
> On 11/19/2013 8:13 PM, Dan Xu wrote:
>> Hi Mandy,
>> I think that writing to the current directory and writing to the temp
>> directory will get the same interference in this testcase. Because the
>> interference is mostly coming from the anti-virus software or some
>> windows system services. Any file changes in the file system may
>> trigger them. Due to the interference, if a test deletes a file and
>> then immediately create a file with the same name, the create
>> operation may fail with access denied exception. I have described it
>> in detail when discussing Chris's webrev,
>> http://openjdk.5641.n7.nabble.com/RFR-8022213-Intermittent-test-failures-in-java-net-URLClassLoader-Add-jdk-testlibrary-FileUtils-java-td165561.html.
>> Thanks!
>> -Dan
>> On 11/19/2013 07:08 PM, Mandy Chung wrote:
>>> On 11/19/2013 3:57 PM, Dan Xu wrote:
>>>> Hi All,
>>>> Please review the simple fix towards Size.java testcase. It failed
>>>> once on windows platform in the recent same binary run, which is
>>>> mostly due to some interferences and the special delete handling on
>>>> windows.
>>>> In the fix, I remove the delete operation in initTestFile() method
>>>> because FileOutputStream will truncate the file content and it is
>>>> not necessary to delete it first. Thanks!
>>>> Bug:https://bugs.openjdk.java.net/browse/JDK-8028628
>>>> Webrev: http://cr.openjdk.java.net/~dxu/8028628/webrev/
>>>> <http://cr.openjdk.java.net/%7Edxu/8028628/webrev/>
>>> The patch itself is okay.   Would you think if writing to a file in
>>> the current directory rather than temp is less prone to the
>>> interference?
>>> Mandy

More information about the core-libs-dev mailing list