Give default value of O_NOFOLLOW if it is not defined
littlee at linux.vnet.ibm.com
Thu Jan 12 21:34:05 PST 2012
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/%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
> 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.
Please check: http://cr.openjdk.java.net/~littlee/7129029/webrev.01/
More information about the nio-dev