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

[Alan Bateman]

On 04/11/2020 00:16, Nhat Nguyen wrote:
> Hi Alan,
>
> Thank you for the suggestion! I tried using toRealPath and noticed this interesting scenario.
>
> Let's assume that we have a drive "Z:" mapped to a sharepoint drive containing file "a.txt" and another soft link "C:/link"
> whose target is "Z:/a.txt". Further assume we want to see if "Z:/a.txt" and "C:/link" are the same.
>
> If we perform toRealPath on both inputs, "Z:/a.txt" will stay as "Z:/a.txt". However, "C:/link" will follow a different code path
> in WindowsLinkSupport.getRealPath where it notices that the input is a reparse point and eventually calls getFinalPath.
> The result for "C:/link" is then "\\sharepointHostName.com at SSL\DavWWWRoot\a.txt". So, we conclude that the
> files are different even though they are the same.
>
> If we use GetFinalPath for both, we will be able to notice that they are the same. I'd love to know what you think about this
> scenario and if it's worth supporting it.
>
I agree we need to re-examine WindowsLinkSupport.getRealPath, at least 
for the followLinks=true case. If I remember correctly, we couldn't rely 
on GetFinalPathNameByHandle because it wasn't available on Windows XP 
and that is historical now. Also there was an issue with needing to open 
the file with backup semantics, I need to page in some of the details 
but I think that was needed for directories. There was another issue 
with sym links on NTFS that linked to files on non-NTFS volumes. If you 
confirm that GetFinalPathNameByHandle is essentially POSIX realpath then 
I would be happy to see WindowsLinkSupport.getRealPath changed to use 
that for the followLinks=true case. It might be that we need a fallback 
for cases where GetFinalPathNameByHandle fails. I'd also would be okay 
with change isSameFile to use toRealPath on both files so that it does 
not rely on the volume or file index.

-Alan