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

[Eric Wang]

Hi David,

Yes, the 3 items are all the changes.
For the -extra option, I also don't know when it should be used, so i 
prefer to remove it to make sure the long path test on windows could be 
always executed in Nightly.
For the Solaris issue, I have executed the test on several Solaris 
machines, but didn't get the timeout issue. Not sure whether the issue 
still exists, so remove it to see if it would be failed in Nightly.

Thanks,
Eric

On 2012/8/28 11:06, David Holmes wrote:
> 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
>>>>
>>