[EXTERNAL] Re: Bug in Files.isSameFile(Path,Path)

Alan Bateman Alan.Bateman at oracle.com
Tue Nov 3 16:41:57 UTC 2020



On 02/11/2020 20:26, Nhat Nguyen wrote:
> Hi Alan,
>
> We got the answers from our internal team.
>
> It turns out that volSerialNumber, as per the Windows Protocol Specs, isn't required to be non-zero [1].
> Fortunately, we can use the file index value to determine whether the file systems support 64 file-index [2].
>
> File index being 0 means the file system doesn't support 64-bit file index. In the case of webdav drive, the
> file index is indeed 0 from my testing. We were also cautioned that file systems that use 128-bit file index
> such as ReFS may return -1 in case the index doesn't fit into a 64-bit value. In such cases, they recommend
> that we use GetFileInformationByHandleEx [3] to get FILE_ID_INFO [4] which returns the 128-bit file id.
>
> The caveat is that FILE_ID_INFO is only supported from Windows 8.0/2012, and NTFS might have only
> implemented it as of 8.1/2012 R2. Furthermore, file systems are not required to implement it.
>  From my testing, webdav drives don't support getting FILE_ID_INFO using GetFileInformationByHandleEx.
>
> Given that FILE_ID_INFO is not fully supported by all versions of Windows which LTS JDK are required to run
> on, and that it isn't required to be implemented by all file systems, we think the simplest and best effort
> is to guard against 0 and -1 for file index, and fall back to comparing paths using GetFinalPathByHandle.
> What is your opinion on this?
>
> Also, we would be very appreciate if you can help us create a JBS bug for this issue so we can open PR
> against it.
>
Thanks for the update and information. I've created JDK-8255844 [1] to 
track this. I think I agree with the general approach. In terms of 
implementation then it might be simplest to add a hasFileIndex method to 
WindowsFileAttributes so that WindowsFileSystemProvider knows if it use 
the file index approach. If not, then fallback to using toRealPath as it 
will do all the checks needed to get the real path.

-Alan

[1] https://bugs.openjdk.java.net/browse/JDK-8255844


More information about the nio-dev mailing list