os.path.samefile (used by shutil copyfile and move), os.path.sameopenfile, and pathlib.samefile rely on os.path.samestat (from genericpath.py), which compares corresponding st_dev and st_ino values. POSIX assures that the tuple (st_dev, st_ino) is unique. Windows makes no such assurance for the combination of the volume serial number (st_dev) and file index number (st_ino). The volume serial number isn't required to be unique or even non-zero ([MS-FSCC] 2.5.9), and the file index number may also be zero if the file system doesn't support it ([MS-FSCC] 2.4.20).

[MS-FSCC]: File System Control Codes
https://msdn.microsoft.com/en-us/library/cc231987

A WebDAV network drive exemplifies both cases. The volume serial number is zero, as is the file index number for every file and directory. Thus samestat() is true for every comparison on the drive, whether for a file or directory, and also when comparing files mounted on different WebDAV drives.

This isn't a common problem, but I think it's severe enough to warrant a separate Windows implementation of samefile and sameopenfile. If the corresponding st_dev and st_ino values are equal and either is zero, it should compare the final paths via _getfinalpathname. The latter would need to be modified to support passing a file descriptor for use with sameopenfile.

Another example of this misbehaviour: there are cases where ``os.stat()`` will internally fail to obtain the whole stat info (in some case related to permissions) and silently fall back to the same behaviour as Python 2.7.  In particular, it will return a result with ``st_dev == st_ino == 0``.  Of course, ``os.path.samefile()`` will then consider all such files as "the same one", which is nonsense.

still an issue with Python 3.8 and 3.9.
A copy between 2 files on webdave mapped drives can't be done, although src and dst are different.

Same as issue33935, but since the newer issue has proposed solutions on it already, I'm preferring to keep that one open.