[PATCH] Review request: 6962637 TEST_BUG: java/io/File/MaxPathLength.java may fail in busy system

David Holmes david.holmes at oracle.com
Tue Aug 28 03:06:12 UTC 2012


Hi Eric,

So removing the disk space stuff seems fine.

Regarding which platform this will run on you have:

- removed checks for obsolete windows platforms
- enabled the general test to now run on Solaris
- changed the test that would only run on windows if -extra was 
specified to now always run on windows

Does that sum it up? The last part makes me wonder when we would run the 
test with -extra, as we will now always exercise this part on windows.

And are we sure the Solaris issues are no longer a concern? I assume the 
problem was doing the disk space checks on remote filesystems.

Thanks,
David

On 28/08/2012 12:52 PM, Eric Wang wrote:
> Hi David, Amy & Alan
>
> Thanks for your review, Based on your comments I have updated the fix
> again, Can you please review again?
> http://dl.dropbox.com/u/90659131/fixes/6962637/webrev/index.html
>
> Thanks,
> Eric
>
>
> On 2012/8/22 17:27, David Holmes wrote:
>> On 22/08/2012 6:10 PM, Eric Wang wrote:
>>> Hi David,
>>>
>>> To use dirFile.length() == 0 to replace the disk space measurement as
>>> guess the original test tries to prove that there's no extra disk spent
>>> when creating empty folders.
>>
>> Sorry I don't understand. File.length() says:
>>
>> public long length()
>>
>> Returns the length of the file denoted by this abstract pathname. The
>> return value is unspecified if this pathname denotes a directory.
>>
>> Where it is required to distinguish an I/O exception from the case
>> that 0L is returned, or where several attributes of the same file are
>> required at the same time, then the Files.readAttributes method may be
>> used.
>>
>> Returns:
>> The length, in bytes, of the file denoted by this abstract pathname,
>> or 0L if the file does not exist. Some operating systems may return 0L
>> for pathnames denoting system-dependent entities such as devices or
>> pipes.
>>
>> ----
>>
>> In this case we verify we have a directory before we do the length()
>> test, which means the return value from length is unspecified.
>>
>> So I don't understand how length() is being used here.
>>
>> David
>> -----
>>
>>
>>> Regards,
>>> Eric
>>>
>>> On 2012/8/22 16:02, David Holmes wrote:
>>>> Hi Eric,
>>>>
>>>> On 22/08/2012 5:54 PM, Eric Wang wrote:
>>>>> Please help to review the fix below for bug **6962637
>>>>> <http://monaco.us.oracle.com/detail.jsf?cr=6962637> TEST_BUG:
>>>>> java/io/File/MaxPathLength.java may fail in busy system
>>>>> http://dl.dropbox.com/u/90659131/fixes/6962637/webrev/index.html
>>>>>
>>>>> Root cause is the test is not reliable when system is busy, if disk
>>>>> space is changed by some other program, test can fail. so the fix
>>>>> is to
>>>>> check file.length() instead of disk space.
>>>>
>>>> I can not figure out what the original version of the test was doing
>>>> with the disk space measurements but I can certainly appreciate that
>>>> they could be changing dynamically while the test is running.
>>>>
>>>> But I don't really understand why dirFile is expected to have a zero
>>>> length ???
>>>>
>>>> David
>>>>
>>>>> Regards,
>>>>> Eric
>>>
>



More information about the core-libs-dev mailing list