[ python-Bugs-919605 ] os.rename() silently overwrites files

[SourceForge.net]

Bugs item #919605, was opened at 2004-03-19 16:11
Message generated for change (Comment added) made by pje
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=919605&group_id=5470

Category: Python Library
Group: Python 2.2.2
>Status: Closed
>Resolution: Wont Fix
Priority: 5
Submitted By: Jozef Behran (jojoworks)
Assigned to: Nobody/Anonymous (nobody)
Summary: os.rename() silently overwrites files

Initial Comment:
Python 2.2.2 from Mandrake GNU/Linux 9.0

os.rename() should throw an exception when the program
tries to rename file to an existing filename. Such a
situation is namely usually caused by a bug in the
calling program. The current behavior (silently
replacing old file content with the new one) is
dangerous to programmer's data.

If the program wants to overwrite files, it can use

try:
  os.rename(old,new)
except IOError:
  os.unlink(new)
  os.rename(old,new)

or something similar to do so.

----------------------------------------------------------------------

>Comment By: Phillip J. Eby (pje)
Date: 2004-03-20 21:25

Message:
Logged In: YES 
user_id=56214

This behavior is as documented.  See:

http://www.python.org/doc/2.2/lib/os-file-dir.html

under 'rename' for details.

Note that 'os.rename' is specifically *intended* to expose
the underlying platform's rename behavior.  On Unix-like
operating systems, this means overwriting the destination,
if present.

Unfortunately, neither Unix nor Windows can safely emulate
the other OS's behavior here, without causing potential race
conditions in a multi-user or multi-process environment. 
Note, for instance, that your example code does not
correctly emulate os.rename()'s current Unix behavior,
because other processes could change the filesystem state
between the various lines of code.

Thus, Python chooses to expose the underlying OS' semantics,
rather than trying to provide a "one-size-fits-all" behavior
which may not be what you want.  For example, in most
applications that I write, I would rather be able to have
the behavior that you are objecting to, because it allows
atomic modifications to files.  But, Windows does not
support this, which means I must use a different approach
there.  In the same way, Unix does not support Windows'
approach (disallowing overwrite).


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=919605&group_id=5470