Give default value of O_NOFOLLOW if it is not defined

[Charles Lee]

Hi Alan,

On 01/04/2012 08:34 PM, Alan Bateman wrote:
> I don't quite understand your comment but the change would be in 
> UnixFileSystemProvider.newDirectoryStream where it decides whether to 
> return a UnixDirectoryStream or a UnixSecureDirectoryStream. Where 
> O_NOFOLLOW is not supported then it will need to return a 
> UnixDirectoryStream.

I was thinking making the UnixNativeDispatcher.supportsAtSysCalls 
consistent. But maybe I am wrong. supportsAtSysCalls should only be 
judged by "at" functions....
There are some platforms which support "at" functions but do not support 
O_NOFOLLOWLINK flag...
You are inspiring me that maybe I should also use lstat some where and 
fail only when "NOFOLLOW_LINK meets link" :-)

>
> I thought we had wording in the spec to cover this but I'm unable to 
> find it. As I'm sure you will understand, changing the attributes of a 
> symbolic link is not very interesting, not feasible in all cases, and 
> the intention is that a provider is not required to support it. I will 
> create a bug to get the javadoc clarified on this point. Given that a 
> provider may support the updating of some attributes, and may not be 
> able update other attributes then all we can do is have the 
> appropriate set* method fail with an IOException. For example your 
> platform may support lchown, in which case it will be able to change 
> the owner of a symbolic link (not interesting but possible). Given 
> that O_NOFOLLOW is the issue for you then I think that all issues 
> should be covered by changing UnixPath.openForAttributeAccess to throw 
> IOException when followLinks is false.
>

In the spec NOFOLLOW_LINKS means "Do not follow symbolic links". So if 
the platform support lstat, lchown etc, does that mean it support 
NOFOLLOW_LINKS? The spec says NOFOLLOW_LINKS like a behavior not a flag 
"O_NOFOLLOW".
It may be a stupid question, maybe someone has already ask that...

> -Alan
>
>
>
>
>


-- 
Yours Charles