RFR: 8005202 - java/util/logging/CheckLockLocationTest.java fail on solars_10

[Daniel Fuchs]

Hi,

I have modified the test to print the user name as well:

http://cr.openjdk.java.net/~dfuchs/webrev_8005202/webrev.01/

-- daniel

On 11/19/13 9:26 PM, Mandy Chung wrote:
>
> On 11/19/2013 12:12 PM, Daniel Fuchs wrote:
>> On 11/19/13 9:04 PM, Mandy Chung wrote:
>>>
>>> On 11/19/2013 11:35 AM, Daniel Fuchs wrote:
>>>>
>>>> I am therefore proposing to add an additional check in the test's
>>>> setUp() method, in order to verify that the directory is indeed
>>>> not writable.
>>>>
>>>
>>> It may be useful to print the owner of the directory in case if it's
>>> running with root permission.
>>
>> OK - I assume I can find that by foraging into the nio Files API?
>>
>
> I think you could use
> java.nio.file.attribute.FileOwnerAttributeView.getOwner() while you may
> need to deal with "acl" vs "posix".
>
>
>>>> webrev:
>>>> http://cr.openjdk.java.net/~dfuchs/webrev_8005202/webrev.00/
>>>>
>>>
>>>   175         final boolean nonWritable =
>>> nonWritableDir.setWritable(false);
>>>   176         final boolean isWritable = Files.isWritable(path);
>>>   177         if (nonWritable && !isWritable) {
>>>
>>> Perhaps it should assert isWriteable if File.setWriteable returns true.
>>
>> I'm not sure we want to fail in that case. I mean - the bug
>> is complaining that the test fails in the first place ;-)
>> I would be inclined to have the test simply skip the non-writable
>> test in both cases where it detects that it didn't manage to create
>> a non-writable dir.
>
> If File.setWriteable returns true and isWriteable is false, it'd be a
> bug that we want to know about.  Perhaps you want to log if the
> directory is writeable or not instead of adding it to the check.
>
> Mandy