A customer wanted to know whether there was a way to determine
whether two paths reside on the same underlying volume.
They were concerned that due to tricks like
SUBST and volume mount points,
the naïve algorithm of comparing drive letters
may prove inadequate.
You can use
to get the volume serial number and the file index.
Even better is to call
FileIdInfo information code,
because ReFS use a 64-bit volume identifier and a 128-bit file identifier
(double the size of NTFS).
There is a small chance that two volumes might happen to have the
same volume identifier, seeing as a 32-bit value (or a 64-bit
value in the case of ReFS) is not quite enough to guarantee
You can try to filter out that case by using
and passing the first file's file handle and the second file's ID.
OpenFileById uses the file handle
to decide what volume to use,
so passing the first file's file handle means
"Open the new file from the same volume that the old file is on."
You can then compare the newly-opened file's
against the object GUID of the intended second file and see if they match.
Actually, I guess you could have gone straight for the object GUID from the outset: Obtain the object GUID for the second file, then try to open the file by its GUID (relative to the first file).
But wait, we're so distracted by answering the customer's question that we don't understand the customer's problem.
The customer explained that they want to create a content-addressable database, but if they find that there's already a database on the same volume, then they can just hard-link the contents together and save disk space.
Oh, so the problem isn't "Determine whether two files are on the same volume (so I can hard-link them)." The problem is "Determine whether two files can be hard-linked."
That problem is much easier to solve. The way to determine whether two files can be hard-linked is to try hard-linking them and seeing if it works. As Jared Parsons noted, the file system is unpredictable.
Do the operations you want and deal with the consequences of failure [...]. To do anything else involves an unreliable prediction in which you still must handle the resulting [failure].
(Jared's article is written for a C# audience, so he talks about exceptions, because that's the C# paradigm for error handling.)