Files.newDirectoryStream(Path, LinkOption...)

Colin Decker cgdecker at google.com
Wed Feb 12 14:55:53 PST 2014


I was running into this issue trying to implement a secure recursive delete
method that can guarantee it won't follow symbolic links to directories, so
I'd say FileSystemProvider-level support for recursive delete would be even
better (though even then, I think it would be good to have this).
Interestingly, it seems that it's possible to implement this provided that
the file system supports SecureDirectoryStream, by opening a
SecureDirectoryStream to the working directory and then using that to open
a SecureDirectoryStream to the path with NOFOLLOW_LINKS.



On Wed, Feb 12, 2014 at 4:50 PM, Alan Bateman <Alan.Bateman at oracle.com>wrote:

> On 12/02/2014 17:45, Colin Decker wrote:
>
>> Why is there no method for opening a DirectoryStream that allows
>> NOFOLLOW_LINKS? SecureDirectoryStream has such a method, but ironically it
>> isn't possible to get a SecureDirectoryStream in the first place without
>> the possibility of following a symbolic link. Any number of other methods,
>> including those for reading attributes and opening streams/channels, do
>> allow NOFOLLOW_LINKS, so why not newDirectoryStream?
>>
> This was deliberate at the time to keep the newDirectoryStream methods
> simple and because NOFOLLOW_LINKS wasn't widely supported (this is also why
> SecureDirectoryStream is not required to be supported). So yes, this means
> you will always follow links when obtaining the initial
> SecureDirectoryStream. It is probably an area that should be looked at
> again in the future although the support for NOFOLLOW_LINKS or equivalent
> is still a bit sparse.
>
> -Alan.
>



-- 
Colin Decker | Software Engineer | cgdecker at google.com | Java Core
Libraries Team
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/nio-dev/attachments/20140212/49fbcc7c/attachment.html 


More information about the nio-dev mailing list