JDK-8259873: (fs) Add java.nio.file.attribute.BasicWithKeyFileAttributeView interface

[Martin Buchholz]

Hmmmm ...

How about inviting Microsoft folk to review?  They should be experts.

I happen to be very interested in file I/O optimization (but as usual not
enough time!) and was hoping filekeys would help us, but I can see they may
be problematic.

People can and do write their own filesystems, with different performance
objectives.  Looking around at Google I see:

$ stat .
=> Inode: 371    Links: 1  Access: 1969-12-31

That's a suspiciously small inode number for a monorepo.  Other data looks
bogus as well.  A filesystem implementer fills in a stat struct with
whatever is at hand, without a promise of uniqueness for use as a filekey.
For robustness, software that does want uniqueness needs to keep a list of
known reliable filesystem implementations.



On Wed, Jan 20, 2021 at 12:14 AM Alan Bateman <Alan.Bateman at oracle.com>
wrote:

> On 20/01/2021 07:55, Martin Buchholz wrote:
> > I'm mostly cheerleading here, and haven't developed for Windows in
> > many years, but ... I agree with the strategy here.  More use of file
> > keys would benefit performance on all platforms.  OTOH I worry that
> > filekeys are inconsistently implemented on different OSes and
> filesystems.
> >
> The recent thread with subject line "Files.isSameFile(Path,Path)" may be
> useful to re-read. The JDK has been using the volume serial number and
> file indexes but they are problematic on some volumes (not guarantee to
> be unique, maybe be zero). The Microsoft folks here have been looking to
> replace the usage with the "full path" (the approximate equivalent to
> realpath).
>
> We did a lot work in JDK 7 to make the default case (not following sym
> links) be efficient on Windows. This is the reason for the internal
> BasicFileAttribuetHolder that FileTreeWalker uses to avoid needing to
> read the file attributes. Maybe we could lean on that internal interface
> and try to find options there before adding to the standard API.
>
> Switching from FindFirstFile/FindNextFile to NtQueryDirectoryInformation
> is definitely worth exploring, it will just take significant time to
> review and will likely go through a few review iterations.
>
> -Alan
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/nio-dev/attachments/20210120/45355fa6/attachment.htm>