os.rename copies when old is in-use - is this deliberate?

["Martin v. Löwis"]

Tony Meyer wrote:
> Thanks for that.  In your opinion, would a documentation patch that  
> explained that this would occur on Windows (after the existing note  
> about the Windows rename not being atomic) be acceptable?

In principle, yes. We cannot do that for every platform, of course,
but it probably won't be necessary for any platform, either.

> (The Windows platform C library for Python 2.4+ is in msvcrt71.dll,  
> right?  Does that mean that behaviour will be consistent across  Windows 
> versions, or could 9x/NT/XP/etc all behave differently?)

The behaviour could be different in principle, yes. I found a KB article
that says that MoveFile, on Windows CE 4.0, on a FAT file system, would
move the file even if it was open.

I'm actually also surprised by the behaviour - I would have expected
that the failure to delete the file after the copy would cause an
error, or that the attempt to open the file with FILE_SHARE_DELETE
would cause an error right away.

Somebody should investigate this with Sysinternal's filemon, to find
out whether the MoveFile operation really succeeds. Perhaps there is
a bug in the CRT, or in Python, also.

Regards,
Martin