Give default value of O_NOFOLLOW if it is not defined

[Charles Lee]

On 01/12/2012 05:43 PM, Alan Bateman wrote:
> On 12/01/2012 07:02, Charles Lee wrote:
>>
>> Hi Alan,
>>
>> Thank you for your review. I have upload a new version on 
>> http://cr.openjdk.java.net/~littlee/7129029/webrev.00/ 
>> <http://cr.openjdk.java.net/%7Elittlee/7129029/webrev.00/> .
>> Would you please help to check it again? Apart from your suggestion, 
>> I also make some changes in UnixCopyFile.java. The situation is the 
>> same as it is in the UnixChannelFactory.java.
>>
>> Thanks in advance :-)
>>
> The changes to UnixCopyFile.java will break copying of sym links (in 
> Files.copy you'll see that it is specified to support NOFOLLOW_LINKS). 
> The implementation doesn't depend on O_NOFOLLOW support so I don't 
> think any changes are required.

I am thinking NOFOLLOW_LINKS is not O_NOFOLLOW again and again....
On the platform, which does not support O_NOFOLLOW, there will be 
occurred that some api supports NOFOLLOW_LINKS, others are not. This 
will be a little confusing.

I agree that, if the implementation does not depend on O_NOFOLLOW, 
NOFOLLOW_LINKS should be allowed. So I am continuing to think that in 
the place where O_NOFOLLOW is used, we can check it to see whether it is 
sym link to stimulate the behaviour of O_NOFOLLOW flag. It means in 
UnixPath.openForAttributeAccess, we can stimulate O_NOFOLLOW with sym 
link checking. It maybe also means we can stimulate O_NOFOLLOW in the 
SecureDirectoryStream to let platform (AIX 7.1) support more powerful 
directory stream without O_NOFOLLOW supported. Unfortunately, I am 
looping ...

>
> UnixChannelFactory.java L224 - this needs to throw UnixException 
> rather than UOE. This will be handled and translated into the 
> appropriate IOException (actually FileSystemException).
>
> Otherwise the changes look okay to me.
>
> -Alan.
>

Please check: http://cr.openjdk.java.net/~littlee/7129029/webrev.01/ 
<http://cr.openjdk.java.net/%7Elittlee/7129029/webrev.01/>

-- 
Yours Charles