gh-81793: always call linkat() from os.link(), if available - #24997
gh-81793: always call linkat() from os.link(), if available#24997takluyver wants to merge 4 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.
|
This PR is stale because it has been open for 30 days with no activity. |
Sorry, something went wrong.
| if (follow_symlinks) { | ||
| PyErr_SetString(PyExc_NotImplementedError, | ||
| "link: follow_symlinks=True unavailable on this platform"); |
There was a problem hiding this comment.
follow_symlinks is true by default, so os.link() will always fail if linkat is not available.
Sorry, something went wrong.
There was a problem hiding this comment.
I think that's desirable? follow_symlinks is documented as true by default, so if that's unlikely to work, it seems better to error out than to ignore it.
linkat has been in Linux since 2006 and FreeBSD since 2009, so hopefully this isn't a case that many people will run into.
Sorry, something went wrong.
There was a problem hiding this comment.
No, it is not desirable. Otherwise we would just not implement os.link() without linkat.
Sorry, something went wrong.
There was a problem hiding this comment.
Well, you could still pass follow_symlinks=False if you're happy with that behaviour, so it's more useful than the function not existing at all. What alternative are you suggesting?
- Should os.link() implement a symlink-following fallback with 2 system calls? Is there a race condition there?
- Should the follow_symlinks default be documented as platform dependent? That would be accurate but surprising, since most functions with that parameter default to True, and it makes it easy to write code that does something slightly different on Mac & Linux.
But is there any relevant platform or configuration where linkat() is not available? It looks like this has been ubiquitous for well over a decade, so maybe the fallback is kind of academic anyway.
Sorry, something went wrong.
There was a problem hiding this comment.
I am working on this issue now.
Sorry, something went wrong.
There was a problem hiding this comment.
See #81793.
Sorry, something went wrong.
|
The following commit authors need to sign the Contributor License Agreement: |
Sorry, something went wrong.
This is a continuation of PR GH-14843 (closes GH-14843), adding a test. I've pasted the original description below.
I had to rework the change a bit; I find the Apple specific stuff confusing, so I hope I've got it right. 😕
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
https://bugs.python.org/issue37612