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 vstinner
Recipients eryksun, paul.moore, stephan, steve.dower, tim.golden, vstinner, zach.ware
Date 2016-10-05.07:34:03
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <>
In-reply-to <>
> In scanning over issue 8828, I see no discussion of the consequences of not using MOVEFILE_COPY_ALLOWED in Antoine's patch, so it appears that this behavior change was unintentional.

Depending on your point of view, it *can* be seen as an enhancement.

See the documentation of MOVEFILE_COPY_ALLOWED: "If the file is
successfully copied to a different volume and the original file is
unable to be deleted, the function succeeds leaving the source file
intact." This behaviour can be seen as a source of bug. It can be
acceptable if if is expected.

Since shutil.move() already implements the copy+delete fallback, I
suggest to *not* change os.rename() but *document* the behaviour

* os.rename() can fail if source and destination are on two different
file systems
* Use shutil.move() to support move to a different directory already
explains well the behaviour when two different filesystems are used:
"... os.rename() is used. Otherwise, src is copied to dst using
copy_function and then remove ..."

I also suggest to mention in shutil.move() doc that the source can be
left undeleted if delete fails for some reason when copy+delete is
Date User Action Args
2016-10-05 07:34:03vstinnersetrecipients: + vstinner, paul.moore, tim.golden, zach.ware, eryksun, steve.dower, stephan
2016-10-05 07:34:03vstinnerlinkissue28356 messages
2016-10-05 07:34:03vstinnercreate