This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author eryksun
Recipients eryksun, fireattack
Date 2021-01-14.23:23:31
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <>
shutil.move() has always fallen back on copy/unlink if os.rename() fails. This used to be clearly documented to account for the behavior of os.rename() in Windows, but the details were obscured over multiple rewrites. Currently the documentation makes it seem that copy/unlink are only used if the destination is on another filesystem.

Anyway, falling back on copy/unlink is sub-optimal as a move operation [1] and should be avoided wherever possible. It would be better to use os.replace() instead of os.rename(). This expands support for an atomic move within a filesystem, and it avoids the need to modify the documentation, except to reference os.replace() instead of os.rename().


[1] As implemented, a copy will not retain the source file's alternate data streams, security descriptor (i.e. owner and access/audit control), file attributes, or extended file attributes. There are additional problems with reparse points other than symlinks, but that's a difficult problem. We don't support raw copying of reparse points, or even high-level support for creating mountpoint (aka junction) reparse points. There's _winapi.CreateJunction, but the current implementation is just for testing purposes.
Date User Action Args
2021-01-14 23:23:32eryksunsetrecipients: + eryksun, fireattack
2021-01-14 23:23:32eryksunsetmessageid: <>
2021-01-14 23:23:32eryksunlinkissue42929 messages
2021-01-14 23:23:31eryksuncreate