gh-72542: State that os.rename() always fails across filesystems on Windows - #154804
Open
MannXo wants to merge 1 commit into
Open
gh-72542: State that os.rename() always fails across filesystems on Windows#154804MannXo wants to merge 1 commit into
MannXo wants to merge 1 commit into
Conversation
Documentation build overview
|
MannXo
force-pushed
the
docs/72542-os-rename-windows-fs
branch
from
July 28, 2026 09:03
d107b89 to
41d172d
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The Windows paragraph of
os.rename()says the operation "may fail" ifsrcanddstare on different filesystems. On Windows it is a certainty, not a possibility, so this changes "may" to "will".This is the wording eryksun asked for in the issue:
That distinction is still accurate.
Modules/posixmodule.ccomputes theMoveFileExWflags asint flags = is_replace ? MOVEFILE_REPLACE_EXISTING : 0, andMOVEFILE_COPY_ALLOWEDdoes not appear anywhere in the file, so a cross-volume move always fails withERROR_NOT_SAME_DEVICE. The Unix paragraph two paragraphs below keeps "may fail on some Unix flavors", which is correct there, and the contrast between the two is the point of the change.A note on why this issue is still open. GH-27376 was merged and it added the cross-filesystem sentence, which is why it looks resolved at a glance, but it used "may" rather than the "will" that was requested. The sentence exists; only the strength of the claim is wrong.
One question
os.replace()has the same "may fail if src and dst are on different filesystems" sentence and shares the Windows code path, so the failure is equally certain there. Its paragraph is platform-neutral, though, and the issue only discussedos.rename(), so I left it alone rather than widening the diff. Happy to add a Windows note there in this PR if you would prefer.Verification
Built the docs with the nit-picky settings the
Docsworkflow uses:check-warnings.pyandsphinx-lintboth exit 0, andsphinx-warnings.txtcontains no warnings forDoc/library/os.rst. Confirmed in the renderedlibrary/os.htmlthat the Windows paragraph reads "The operation will fail" while the Unix paragraph still reads "may fail on some Unix flavors".No
Misc/NEWS.dentry, since this is documentation only.