bpo-37612: always call linkat() from os.link(), if available - #14843
bpo-37612: always call linkat() from os.link(), if available#14843jo-he wants to merge 2 commits into
Conversation
Sorry, something went wrong.
The issue with link() is that POSIX does not define its behavior regarding symbolic links: "If path1 names a symbolic link, it is implementation-defined whether link() follows the symbolic link, or creates a new link to the symbolic link itself." And it is indeed implemented differently on Linux and NetBSD.
|
As I understand it from your bpo report, the issue is that the behavior of os.link doesn't match its documentation on some platforms (in particular Linux), and this fixes things so that it does. In particular the actual behavior on such platforms makes follow_symlinks=True useless, even when explicitly specified, so that's definitely a bug. (Also you located the relevant provision in POSIX and found that Linux's behavior here is perfectly compliant.) That sounds like a good fix to me! Would you add a test for it? See test_os.py, or perhaps test_posix.py if the test doesn't make sense to run on Windows. |
Sorry, something went wrong.
|
I've had a go at adding the test in #24997. |
Sorry, something went wrong.
|
The following commit authors need to sign the Contributor License Agreement: |
Sorry, something went wrong.
The issue with link() is, that POSIX does not define its behavior regarding symbolic links:
"If path1 names a symbolic link, it is implementation-defined whether link() follows the symbolic link, or creates a new link to the symbolic link itself."
And it is indeed implemented differently on e.g. Linux and NetBSD. So, it makes no sense to call link(), where linkat() is available.
https://bugs.python.org/issue37612