Jason R. Coombs <jar...@jaraco.com> added the comment:
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'))"
c:\Users\jaraco\temp\foo
~ # py -3.8 -c "import os; print(os.readlink('temp/bar'))"
\\?\c:\Users\jaraco\temp\foo
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.
[1]: https://docs.python.org/3/library/shutil.html#shutil.copytree
----------
_______________________________________
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue40654>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
