Thanks Steve. While I was able to avoid the original symptom by not using readlink, I still think there's an issue here, both in the surprising behavior observed by shutil.copyfile, but also by the essential behavior of readlink. The more essential issue can be illustrated this simple problem: how could one write the `cmd.exe` `dir` command using Python? Using cmd.exe:

```
C:\Users\jaraco>mklink foo C:\USERS\jaraco\bar
symbolic link created for foo <<===>> C:\USERS\jaraco\bar

C:\Users\jaraco>dir foo
 Volume in drive C has no label.
 Volume Serial Number is B8F4-40BB

 Directory of C:\Users\jaraco

2020-05-26  02:04 AM    <SYMLINK>      foo [C:\USERS\jaraco\bar]
               1 File(s)              0 bytes
               0 Dir(s)  21,078,786,048 bytes free
```

Similarly in powershell:

```
PS C:\Users\jaraco> cmd /c mklink foo c:\users\jaraco\bar
symbolic link created for foo <<===>> c:\users\jaraco\bar
PS C:\Users\jaraco> dir 'foo' | ?{$_.LinkType} | select Target

Target
------
{c:\users\jaraco\bar}
```

Whether 'bar' exists or not, it seems to me that these tools use the "print name" to render the next hop of the link to the user (even if that target doesn't exist).

`realpath` doesn't provide this functionality and neither does `readlink`.

Perhaps more importantly, the "print name" is lost when copying the file using shutil, but for the same underlying reason--the print name is not exposed by the low level API, and the result is that implementation details about the platform leak out to the user interface.

If "\\?\C:\Users\jaraco\bar" is the more correct form of the target, then shouldn't these tools also be exposing that value to the user? How would a Python developer wishing to implement the dir command do so? Is there a way to retain the fidelity of the print name during an shutil.copy?