> I don't see any value in testing the drive name separately. 

If the file number is non-zero, then the volume is the only question. I limited the comparison to just the drives in case the volume supports hardlinks. We can change the check to `s1.st_ino and s1.st_nlink > 1`, so we only incur the expense when necessary. Maybe that's never in practice, but I'd rather error on the side of caution.

Anyway, it turns out we can't use splitdrive(). It doesn't handle UNC device paths the same way as regular UNC paths. It returns "\\?\UNC" as the drive for "\\?\UNC\server\share", whereas for a regular UNC path the drive is "\\server\share". 

> Would it make sense to add a parameter to _getfinalpathname that 
> specifies the type of the path? For same[open]file(), we can 
> probably just go to the most unreadable but broadly supported 
> type

That's probably the simplest change we can make here, in addition to file-descriptor support. The non-normalized NT path (VOLUME_NAME_NT | FILE_NAME_OPENED) is the most broadly supported and cheapest path to get. It's just two system calls: NtQueryObject and NtQueryInformationFile.