[Python-Dev] os.rename() behavior

[Guido van Rossum]

> 
>   rename(src, dst)
> 
>   Rename the file or directory src to dst. If dst is a directory,
>   OSError will be raised. On Unix, if dst exists and is a file, it will
>   be removed silently if the user has permission. The operation may fail
>   on some Unix flavors if src and dst are on different filesystems. If
>   successful, the renaming will be an atomic operation (this is a POSIX
>   requirement). On Windows, if dst already exists, OSError will be
>   raised even if it is a file; there may be no way to implement an
>   atomic rename when dst names an existing file. Availability:
>   Macintosh, Unix, Windows.
> 
> 
> While I understand that this is an operating system behavior, and the os
> module is meant to hold incompatible functionality, I do belive that
> most of us developing in posix systems have never checked if a rename
> failed because the file already exists. IOW, this will usually be
> discovered when the program blows up for the first time in Windows
> (that's how Thomas discovered).
> 
> Is it too late to implement the forced rename internally, and leave the
> programmer test it with os.path.exists() if he really wants to?
> 
> I know this will cause incompatibilities in programs which expect the
> current behavior. OTOH, programs that expect this behavior are already
> broken in any posix system.

-1.

The Unix semantics can't be properly emulated on Windows, because it
is guaranteed to be *atomic*.  Python can't know whether an
applications that blindly assumed Unix semantics is relying on the
atomicity; if the application needs this, doing a remove() first under
the cover would be a grave error (especially more grave since the
potential data loss is unlikely to be found through testing).

--Guido van Rossum (home page: http://www.python.org/~guido/)