Author jaraco
Recipients eryksun, jaraco, paul.moore, steve.dower, tim.golden, zach.ware
Date 2020-05-17.14:56:41
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <>
Thank you Eryk for the thorough and informative investigation. Seriously, wow.

> Do you want 3.8 to revert to using the print name, at least for symlinks? (ntpath._readlink_deep would need to be modified to support long target paths.) Or would you rather that shutil used a more reliable way to copy symlinks verbatim on Windows? For example, use CopyFileExW for a file and CreateDirectoryEx for a directory.

In this case, my instinct is that `shutil` should devise a more reliable way to copy symlinks. It claims that it does to the extent the platform allows [1].

> symbolic links in the source tree are represented as symbolic links in the new tree and the metadata of the original links will be copied as far as the platform allows

It hadn't occurred to me that the effect may be manifest in readlink, but I see that now too:

~ # py -3.7 -c "import os; print(os.readlink('temp/bar'))"
~ # py -3.8 -c "import os; print(os.readlink('temp/bar'))"

So even if shutil.copyfile were to copy the symlinks exactly, the expectation would still be missed that the output of readlink doesn't match the input to symlink, so the expectation would still be missed. A user/programmer should be able to predict the output of 'readlink' given the input to 'symlink' (or cmd /c mklink).

Based on that reasoning, my answer would be "both", but I'd put a priority on restoring the use of "print name" for `readlink`, as that may be sufficient to satisfy most (if not all) use-cases.

Date User Action Args
2020-05-17 14:56:41jaracosetrecipients: + jaraco, paul.moore, tim.golden, zach.ware, eryksun, steve.dower
2020-05-17 14:56:41jaracosetmessageid: <>
2020-05-17 14:56:41jaracolinkissue40654 messages
2020-05-17 14:56:41jaracocreate