File Attributes from DirectoryStream (WindowsPathWithAttributes)?

[Bernd Eckenfels]

Hello Alan,

I don’t use it yet, I was looking for a way to use it with an official way. While caching is tricky especially in listing a directory it is very beneficial. Today Code like (Files.isReadable(p) && !Files.isDirectory(p)) will hit the filesystems with two additional stat calls  even when it just returned the file entry from a list call.

However, I did not consider to use the walkFileTree() method before, since I had no need to recurse into subdirectories, but since you mentioned it: checking it again I see that it actually features a callback with the BasicFileAttributes, which seems to be exactly the official API I was looking for.

Thanks for getting back to this question.

BTW: the current code seems to not cache the direntry for FindFirst, it does need one additional roundtrip per subdirectory, therefore.

Gruss
Bernd
--
http://bernd.eckenfels.net

________________________________
Von: Alan Bateman <alan.bateman at oracle.com>
Gesendet: Montag, August 27, 2018 8:43 AM
An: Bernd Eckenfels; nio-dev at openjdk.java.net
Betreff: Re: File Attributes from DirectoryStream (WindowsPathWithAttributes)?

On 10/08/2018 07:05, Bernd Eckenfels wrote:
> Hello,
>
> in sun.nio.fs.WindowsDirectoryStream I see that the code which iterates the Directory goes to some length to retain the file attributes returned from that function (by attaching them to a WindowsPathWithAttributes (aka BasicFileAttributesHolder).
>
> And indeed I can see that class in my DirectroyStream Iterator or Filter. However I do not see that the normal WindowsFilesystemProvider (or actually WindowsFileAttributes#get() check for instances of that. This way None of the Files.getAttributeView seem to Benefit from that.
>
> So I wonder is this missing or is there some other way you are supposed to work with this cached Attributes?
>
> For 8 I can work with instanceof, but that might no longer be an Option with JPMS.
>
The caching you have found is for use when walking a file tree
(walkFileTree and walk methods). It is not valid to cache attributes as
you are suggesting as the file may have changed or may even be a
different file.

If I read your mail correctly then you making direct use of sun.nio.fs.*
classes. These are JDK internal and no guarantee that they won't change
at any time. Also you will have issues at both compile-time and run time
once the java.base module is fully encapsulated.

-Alan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/nio-dev/attachments/20180827/6ddeb384/attachment.html>