Give default value of O_NOFOLLOW if it is not defined

[Charles Lee]

Hi Alan,

On 12/30/2011 11:27 PM, Alan Bateman wrote:
> On 29/12/2011 03:27, Charles Lee wrote:
>>
>> Hi Alan,
>>
>> I have the same concern. So I did a grep on "LinkOption" and found 
>> that the Usage of O_NOFOLLOW fell into two categories:
>> 1. used to make a value to a boolean: flags.followLinks,  
>> Util.followLinks. In this situation give O_NOFOLLOW to 0 will do no 
>> harm.
>> 2. pass a part of flags to the native directly: open and openat in 
>> the UnixChannelFactory, UnixPath and UnixSecureDirectoryStream. In 
>> this situation, maybe we should throw UnsupportedOperationException?
>>
>> What do you think if I use 0 as a flag to O_NOFOLLOW is not supported?
>>
> I'll send mail when I get back next week but off-hand:
>
> 1. SecureDirectoryStream can't be supported on platforms that don't 
> have O_NOFOLLOW so it means that 
> UnixFileSystemProvider.newDirectoryStream will require to check this 
> before deciding the type of DirectoryStream to return.

I agree with you. Just simply changing the code in the  
NativeDispatcher's init method will make it happen.

>
> 2. UnixChannelFactory (which is used by 
> UnixFileSystemProvider.newFileChannel and newAsynchronousFileChannel) 
> will need to fail with UOE if NOFOLLOW_LINKS is specified as an option 
> when opening a file. It's not one of the standard opens and so it's 
> required to be supported, it just happens that all the platforms we 
> currently

This part of code is a bit tricky. Because !CREATE_NEW && 
DELETE_ON_CLOSE will still need O_NOFOLLOW. It will be strange for user 
if they do not know the details of implementation but get "Unsupported 
no follow option" only because they use !CREATE_NEW && DELETE_ON_CLOSE. 
Can I remove the !CREATE_NEW && DELETE_ON_CLOSE ?

>
> 3. Where a FileAttributeView is created that doesn't follow sym links 
> then it's highly platform specific if it can be used to update the 
> attributes of the sym link. This is where 
> UnixPath.openForAttributeAccess is used. I need to double check the 
> javadoc to see how this is specified as I can't recall off-hand if 
> this is treated as an UOE or an IOException (I think the latter).
>

 From the code and doc, I guess it throws IOException. It is interesting 
that methods in the FileSystemProvider throw UOE because not supporting 
specific attribute view, not include not supporting options. Can we add 
this in the doc? I'd like a UOE been throw in the FileSystemProvider if 
a method is provided a NOFOLLOW_LINKS on the platform which is not 
supported O_NOFOLLOW. This will include all the methods which has option 
as its parameter in the FileSystemProvider. What do you think, Alan?

> -Alan.
>


-- 
Yours Charles