STINNER Victor added the comment: > 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 change: * os.rename() can fail if source and destination are on two different file systems * Use shutil.move() to support move to a different directory https://docs.python.org/dev/library/shutil.html#shutil.move 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 used. ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue28356> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
