classification
Title: Atomic function to rename a file
Type: enhancement Stage: resolved
Components: Library (Lib), Windows Versions: Python 3.3
process
Status: closed Resolution: fixed
Dependencies: Superseder:
Assigned To: Nosy List: Trundle, draghuram, eric.araujo, giampaolo.rodola, haypo, neologix, pitrou, python-dev, r.david.murray, tarek, techtonik
Priority: normal Keywords: patch

Created on 2010-05-26 23:41 by haypo, last changed 2012-01-30 21:13 by pitrou. This issue is now closed.

Files
File name Uploaded Description Edit
atomic_move_file-windows.py haypo, 2010-06-09 22:52
osreplace.patch pitrou, 2012-01-26 15:46 review
Messages (47)
msg106587 - (view) Author: STINNER Victor (haypo) * (Python committer) Date: 2010-05-26 23:41
os.rename() is atomic on Linux, but on Windows it raises an error if the destination does already exist.

Not atomic pseudo-code for Windows:
  if exists(b):
     unlink(b)
  rename(a, b)

Windows offers different functions depending on the version:
 - MoveFileTransacted(): atomic! version >= (Windows Vista, Windows Server 2008)
 - ReplaceFile(): version >= Windows 2000
 - MoveFileEx() with MOVEFILE_REPLACE_EXISTING and MOVEFILE_WRITE_THROUGH flags: not atomic (eg. "If the file is to be moved to a different volume, the function simulates the move by using the CopyFile and DeleteFile functions."), version >= Windows 2000

I don't think that it's possible to write an atomic rename (file) function for any OS, so it's only a "best effort" atomic function. The documentation will give a list of OS on which the operation *is* atomic (eg. Linux).

Note: os.rename() uses MoveFileW() on Windows.
msg106599 - (view) Author: STINNER Victor (haypo) * (Python committer) Date: 2010-05-27 09:45
A first implementation can be:

if os.name in ('nt', 'ce'):
   def atomic_rename(a, b):
      if os.path.exists(b):
         unlink(b)
      rename(a, b)
else:
   atomic_rename = os.rename

This implementation is atomic on POSIX, and not atomic on Windows. Tell me if I am wrong.

It can be improved later by adding the support of better Windows functions.
msg106600 - (view) Author: STINNER Victor (haypo) * (Python committer) Date: 2010-05-27 09:47
See issue #8604: proposal of a new "with atomic_write(filename) as fp: ..." context manager.
msg106601 - (view) Author: STINNER Victor (haypo) * (Python committer) Date: 2010-05-27 09:58
Begin by removing the dest file is maybe not the safer approach :-) Here is a new try: begin by renaming the dest file to a new file.

------
# use maybe a PRNG instead of a dummy counter or tempfile
def _create_old_filename(filename):
   old = filename + '.old'
   index = 2
   while os.path.exists(old):
      old = filename + '-%s.old' % index
      index += 1
   return old

if os.name in ('nt', 'ce'):
   def atomic_rename(src, dst):
      if os.path.exists(dst):
         old = _create_old_filename(dst)
         rename(dst, old)
         rename(src, dst)
         unlink(old)
      else:
         rename(src, dst)
else:
   atomic_rename = os.rename
------

What can we do if "rename(src, dst)" fails?
msg106602 - (view) Author: STINNER Victor (haypo) * (Python committer) Date: 2010-05-27 10:10
> This implementation is atomic on POSIX, ...

Wrong :-)


"On how rename is broken in Mac OS X"
http://www.weirdnet.nl/apple/rename.html

"Update January 8, 2010: ... the original bug (5398777) was resolved in Snow Leopard but the issue I reported was not fixed. ..."
msg106603 - (view) Author: STINNER Victor (haypo) * (Python committer) Date: 2010-05-27 10:32
We have to think about network file systems like NFS. Gnome (nautilus) had a bug on rename because NFS emitted a delete notification on a rename:
http://linux-nfs.org/pipermail/nfsv4/2009-March/010134.html
https://bugzilla.gnome.org/show_bug.cgi?id=575684

It looks like rename is atomic, it's just a bug about notification. But other virtual file systems may not implement atomic rename (eg. is rename atomic with sshfs?). Should Python detect the file system type to choose the algorithm? I would like to say no, because I consider that as a file system (or kernel) bug, not a Python bug.

--

Should we also implement a atomic version of shutil.move()? Support rename if the source and the destination are on different file systems. Or is shutil.move() already atomic?

Note: this issue is only about renaming a *file*. Atomic rename of a directory is much more complex :-)
msg106604 - (view) Author: Antoine Pitrou (pitrou) * (Python committer) Date: 2010-05-27 10:44
It seems you are proposing to call "atomic" something which isn't atomic:

   def atomic_rename(src, dst):
      if os.path.exists(dst):
         old = _create_old_filename(dst)
         rename(dst, old)
         rename(src, dst)
         unlink(old)
msg106605 - (view) Author: STINNER Victor (haypo) * (Python committer) Date: 2010-05-27 10:51
@pitrou: Yes, as I wrote: it's not possible to write an atomic function for all OS. The documentation must give a list of the OS on which the function is atomic. Would you prefer to not define the function instead of writing a pseudo-atomic function?

--

Java bug opened in 1996, closed with "Will Not Fix", last comment ("i am facing similar issue...") in 2008:
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4017593

"How to do atomic writes in a file" in a MSDN blog:
http://blogs.msdn.com/b/adioltean/archive/2005/12/28/507866.aspx

Extract: "Sometimes shell operations like Delete, Rename can fail for various reasons. For example, it might just happen that an antivirus or content indexing application randomly scans the whole file system once in a while. So, potentially, the file Foo.Tmp.txt will be opened for a short period which will cause ... failed delete. And, not only that, but also Rename can fail if the old file already exists, and someone has an open handle on it."

To avoid that "antivirus or content indexing application" open the file, we may need to use a lock on the files.
msg106608 - (view) Author: Antoine Pitrou (pitrou) * (Python committer) Date: 2010-05-27 12:11
> Would you prefer to not define the function instead of writing a pseudo-
> atomic function?

Your current implementation is useless, since it doesn't achieve anything new.
Besides, if the function isn't atomic, don't name it atomic_XXX.
msg106609 - (view) Author: STINNER Victor (haypo) * (Python committer) Date: 2010-05-27 12:24
> Antoine Pitrou <pitrou@free.fr> added the comment:
> > Would you prefer to not define the function instead of writing a pseudo-
> > atomic function?
> 
> Your current implementation is useless, since it doesn't achieve anything
> new. Besides, if the function isn't atomic, don't name it atomic_XXX.

Someone may reimplement it with unlink+rename which is worse :-)

But ok, you prefer to not define the function if no real atomic implementation 
can be written.
msg107070 - (view) Author: R. David Murray (r.david.murray) * (Python committer) Date: 2010-06-04 15:42
Victor: you could always name it best_effort_at_atomic_rename :)
msg107257 - (view) Author: anatoly techtonik (techtonik) Date: 2010-06-07 07:56
Atomic file renames are reimplemented by:
1. Mercurial
2. Trac
3. Dulwich (aka HgGit)

and essential for many other projects out there, so this should be in standard library. Atomic renames depend on filesystem more that on the OS.
msg107264 - (view) Author: STINNER Victor (haypo) * (Python committer) Date: 2010-06-07 11:27
Implementation of "atomic" rename() for Windows in Mercurial:
http://selenic.com/repo/hg/file/tip/mercurial/windows.py
(search for "def rename")
msg107269 - (view) Author: anatoly techtonik (techtonik) Date: 2010-06-07 17:06
Dulwich bug discussion (closed) - https://bugs.edge.launchpad.net/dulwich/+bug/557585

Trac implementation - http://trac.edgewall.org/browser/trunk/trac/util/__init__.py?#L82

Stackoverflow - http://stackoverflow.com/questions/167414/is-an-atomic-file-rename-with-overwrite-possible-on-windows
msg107433 - (view) Author: STINNER Victor (haypo) * (Python committer) Date: 2010-06-09 22:46
About the function names:
 - shutil.atomic_move_file(): only available on some OS
 - shutil.move_file(): use shutil.atomic_move_file() if available, or fall back to a best effort implementation

Implement an atomic function to rename a directory is more complex and should be done in another issue. That's why I added "_file" suffix.
msg107434 - (view) Author: STINNER Victor (haypo) * (Python committer) Date: 2010-06-09 22:52
[atomic_move_file-windows.py]: implementation of atomic_move_file() for Windows, depends on CreateTransaction() and MoveFileTransacted(), only available on Windows Vista, Windows Server 2008, or more recent version. This function *is* atomic.

This function is also able to rename a directory!
msg107449 - (view) Author: anatoly techtonik (techtonik) Date: 2010-06-10 09:36
Does it work with FAT32 or network filesystem?
msg143995 - (view) Author: STINNER Victor (haypo) * (Python committer) Date: 2011-09-13 23:21
According to the following article, a fsync is also needed on the directory after a rename. I don't understand if is it always needed for an atomic rename, or if we only need it for the "atomic write" pattern.

http://lwn.net/Articles/457667/

"The more subtle usages deal with newly created files, or overwriting existing files. A newly created file may require an fsync() of not just the file itself, but also of the directory in which it was created (since this is where the file system looks to find your file). This behavior is actually file system (and mount option) dependent. You can either code specifically for each file system and mount option combination, or just perform fsync() calls on the directories to ensure that your code is portable."
msg144011 - (view) Author: Charles-François Natali (neologix) * (Python committer) Date: 2011-09-14 06:53
> According to the following article, a fsync is also needed on the 
> directory after a rename. I don't understand if is it always needed for 
> an atomic rename, or if we only need it for the "atomic write" pattern.

It's not needed if you just want atomicity, i.e. the file is visible either under its old name or its new name, but not neither or both.
If is however needed if you want durability, i.e. you want to guarantee that the file is visible under its new name after your atomic_rename returns.
msg146226 - (view) Author: Charles-François Natali (neologix) * (Python committer) Date: 2011-10-23 11:07
The recent issue #13146 renewed my interest, so I'd like to make this move forward, since I think an atomic rename/write API could be quite useful.
Issue #8604 (Adding an atomic FS write API) can be achieved relatively easily with the typical (fsync() left aside)
- create temporary file
- write to the temp file
- atomically rename the temp file to the target path

But the problem is that rename is only atomic on POSIX, and not on Windows.
So I'd suggest to:
- rename this issue to target specifically Windows ;-)
- add MoveFileTransacted to the standard library (PC/msvcrtmodule.c, posixmodule?)

I'm -1 on exposing a "best effort" atomic rename/file API: either the OS offers the primitives necessary to achieve atomicity, or it doesn't. It's better to have a working implementation on some OSes than a flaky implementation on every OS.

Note that I'll happily take over the atomic file API part (issue #8604), but since my Windows kung-fu is so poor, it'd be nice if someone with some Windows experience could tackle this MoveFileTransacted
msg146273 - (view) Author: Antoine Pitrou (pitrou) * (Python committer) Date: 2011-10-24 00:23
MoveFileTransacted is only available under Vista or later. You should be able to use MoveFileEx for the same effect.
msg146274 - (view) Author: Antoine Pitrou (pitrou) * (Python committer) Date: 2011-10-24 00:27
"The solution? Let's remember that metadata changes are atomic. Rename is such a case."

This is from a MSDN blog, I would hope he knows what he's talking about.
http://blogs.msdn.com/b/adioltean/archive/2005/12/28/507866.aspx

(MoveFileEx appears in Windows XP, which is fine: in Python 3.3, "Windows 2000 and Windows platforms which set COMSPEC to command.com are no longer supported due to maintenance burden")
msg146280 - (view) Author: Charles-François Natali (neologix) * (Python committer) Date: 2011-10-24 06:56
> MoveFileTransacted is only available under Vista or later. You should be able to use MoveFileEx for the same effect.

Nice.

> "The solution? Let's remember that metadata changes are atomic. Rename is such a case."
>

Hmmm.
Is he referring to the "standard" rename? The blog doesn't evoke a
specific function, but if it was the case, then why bother at all?

By the way:
"""
 - MoveFileEx() with MOVEFILE_REPLACE_EXISTING and
MOVEFILE_WRITE_THROUGH flags: not atomic (eg. "If the file is to be
moved to a different volume, the function simulates the move by using
the CopyFile and DeleteFile functions."), version >= Windows 2000
"""

There's exactly the same limitation with the POSIX version (except
that it'll fail with EXDEV instead of silently doing the copy+unlink).
msg146282 - (view) Author: Antoine Pitrou (pitrou) * (Python committer) Date: 2011-10-24 08:47
> > "The solution? Let's remember that metadata changes are atomic. Rename is such a case."
> >
> 
> Hmmm.
> Is he referring to the "standard" rename? The blog doesn't evoke a
> specific function, but if it was the case, then why bother at all?

Standard rename (MoveFile) fails when the target exists, and that's
AFAICT the whole problem with it. MoveFileEx allows to overwrite the
target with MOVEFILE_REPLACE_EXISTING.

> By the way:
> """
>  - MoveFileEx() with MOVEFILE_REPLACE_EXISTING and
> MOVEFILE_WRITE_THROUGH flags: not atomic (eg. "If the file is to be
> moved to a different volume, the function simulates the move by using
> the CopyFile and DeleteFile functions."), version >= Windows 2000
> """
> 
> There's exactly the same limitation with the POSIX version (except
> that it'll fail with EXDEV instead of silently doing the copy+unlink).

If you don't specify the MOVEFILE_COPY_ALLOWED flag, MoveFileEx also
fails. I don't understand what Victor was trying to say.
msg146307 - (view) Author: Antoine Pitrou (pitrou) * (Python committer) Date: 2011-10-24 16:40
I see that Sun/Oracle Java trusts MoveFileEx to do atomic renames:

  290           // atomic case
  291           if (atomicMove) {
  292               try {
  293                   MoveFileEx(sourcePath, targetPath, MOVEFILE_REPLACE_EXISTING);
  294               } catch (WindowsException x) {
  295                   if (x.lastError() == ERROR_NOT_SAME_DEVICE) {
  296                       throw new AtomicMoveNotSupportedException(
  297                           source.getPathForExceptionMessage(),
  298                           target.getPathForExceptionMessage(),
  299                           x.errorString());
  300                   }
  301                   x.rethrowAsIOException(source, target);
  302               }
  303               return;
  304           }

(from http://www.docjar.com/html/api/sun/nio/fs/WindowsFileCopy.java.html )
msg150149 - (view) Author: Antoine Pitrou (pitrou) * (Python committer) Date: 2011-12-23 11:05
So how about providing a new public `os` module function doing a rename-with-overwrite on all platforms?
We could name it e.g. os.replace().
os.rename_overwrite() is another possibility, more explicit but also longer.
msg150166 - (view) Author: R. David Murray (r.david.murray) * (Python committer) Date: 2011-12-23 15:22
What is the motivation for providing a new function?
msg150168 - (view) Author: Antoine Pitrou (pitrou) * (Python committer) Date: 2011-12-23 15:28
> What is the motivation for providing a new function?

Because changing os.rename would break compatibility.
msg150170 - (view) Author: R. David Murray (r.david.murray) * (Python committer) Date: 2011-12-23 15:39
Ah, I see, people may be depending on rename on Windows not overwriting.

I suppose a new function (and eventually deprecating the old?) would be the most straightforward way forward, though I dislike the necessity :)

An alternative might be a flag on rename: overwrite=['always', 'os_default'], with a warning and a switch of the default in a subsequent release.  That's ugly too, of course.  The existing per-platform variation in behavior of rename gives us a mess to deal with.
msg150175 - (view) Author: Charles-François Natali (neologix) * (Python committer) Date: 2011-12-23 15:53
I'd prefer an optional flag to rename() too.
I really don't like having different functions that achieve the same thing.
It's not obvious to infer from 'replace' its real intent, since it
doesn't match any standard syscall/library.
Ideally, this should be made an option to rename(), especially since
on Unix this will just perform a standard rename.
Another advantage of options over new functions is that it reduces
boilerplate code (i.e. argument parsing, addition to posix_methods,
repeating OS idiosyncrasies/conditional compilation blocks, docstring,
documentation block...).
But I remember Martin thinks that the os module should just be a thin wrapper around underlying syscalls/libraries (but we already have listdir() and friends).
msg150176 - (view) Author: anatoly techtonik (techtonik) Date: 2011-12-23 15:58
os.rename(overwrite=True) to produce consistent cross-platform behavior.
msg150177 - (view) Author: Antoine Pitrou (pitrou) * (Python committer) Date: 2011-12-23 16:08
> An alternative might be a flag on rename: overwrite=['always', 'os_default']

How about overwrite=[None, True] with None meaning "OS default"?

> with a warning and a switch of the default in a subsequent release.

I think we should be conservative with warnings and
compatibility-breaking changes. In this case there's no pressing need to
change behaviour: the default isn't less secure or less efficient.
msg150179 - (view) Author: anatoly techtonik (techtonik) Date: 2011-12-23 16:15
One of the Python advantages is providing predictable cross-platform behavior.  If we can't introduce nice API without BC break, it is not a reason to introduce ulgy API.
msg150180 - (view) Author: R. David Murray (r.david.murray) * (Python committer) Date: 2011-12-23 16:22
I'm good with None/True, but that would imply that for posix rename we'll need to implement the overwrite=False option...which would be a nice thing (the shell mv command has -i for that).

I think a warning would be good, because a unix programmer will assume rename will work the same on windows as it does on posix, and vice versa for a windows programmer.  I suppose the fact that we haven't gotten many (any?) complaints about it means it isn't that common a problem, though, so I don't feel strongly about it.
msg150181 - (view) Author: Antoine Pitrou (pitrou) * (Python committer) Date: 2011-12-23 16:30
> I'm good with None/True, but that would imply that for posix rename
> we'll need to implement the overwrite=False option...which would be a
> nice thing (the shell mv command has -i for that).

My point was rather to forbid False as a value (on all OSes) :)

> I think a warning would be good, because a unix programmer will assume
> rename will work the same on windows as it does on posix, and vice
> versa for a windows programmer.

It is already documented. I don't think we want to add a warning for
every documented peculiar piece of behaviour.
msg150182 - (view) Author: Charles-François Natali (neologix) * (Python committer) Date: 2011-12-23 16:30
> How about overwrite=[None, True] with None meaning "OS default"?

+1.

> One of the Python advantages is providing predictable cross-platform 
> behavior. If we can't introduce nice API without BC break, it is not
> a reason to introduce ulgy API.

We cannot make rename() overwrite existing files by default (on Windows).
It's out of question, too much code might rely on this, and this may very well introduce security flaws.
If you're concerned with the semantics difference between platforms, well, there's not much we can do about it now. Java behaves in the same way, for example.

> I'm good with None/True, but that would imply that for posix rename 
> we'll need to implement the overwrite=False option...which would be a 
> nice thing (the shell mv command has -i for that).

Why?
The problem is that it's simply impossible to implement reliably.
I didn't check mv source code, but it must be using something like:

if '-i' and os.path.exists(target_path):
    continue
os.rename(src_path, target_path).

But there's a TOCTTOU race.
msg150183 - (view) Author: R. David Murray (r.david.murray) * (Python committer) Date: 2011-12-23 16:46
Ah, you are right about the race of course.  So yes, I agree with your proposal.  It's a weird API, but probably the best we can do.
msg150186 - (view) Author: anatoly techtonik (techtonik) Date: 2011-12-23 17:26
2011/12/23 Charles-François Natali <report@bugs.python.org>
>
> > One of the Python advantages is providing predictable cross-platform
> > behavior. If we can't introduce nice API without BC break, it is not
> > a reason to introduce ulgy API.
>
> We cannot make rename() overwrite existing files by default (on Windows).
> It's out of question, too much code might rely on this, and this may very
> well introduce security flaws.
> If you're concerned with the semantics difference between platforms, well,
> there's not much we can do about it now. Java behaves in the same way, for
> example.
>

I propose quite the opposite. rename() should not overwrite existing files
by default.
msg150188 - (view) Author: Charles-François Natali (neologix) * (Python committer) Date: 2011-12-23 17:32
> I propose quite the opposite. rename() should not overwrite existing
> files by default.

1. That's not what I understood from:
> os.rename(overwrite=True) to produce consistent cross-platform 
> behavior.

2. The above argument on backward incompatible change applies in exactly the same way (just exchange Windows for POSIX).

3. As explained above, it can not be done reliably on POSIX (TOCTTOU race).
msg150192 - (view) Author: anatoly techtonik (techtonik) Date: 2011-12-23 19:29
2011/12/23 Charles-François Natali <report@bugs.python.org>

>
> Charles-François Natali <neologix@free.fr> added the comment:
>
> > I propose quite the opposite. rename() should not overwrite existing
> > files by default.
>
> 1. That's not what I understood from:
> > os.rename(overwrite=True) to produce consistent cross-platform
> > behavior.
>
> 2. The above argument on backward incompatible change applies in exactly
> the same way (just exchange Windows for POSIX).
>
> 3. As explained above, it can not be done reliably on POSIX (TOCTTOU race).

os.rename(overwrite=False) by default will do less harm than the opposite,
so I'd say it is a way to go even if it can not be reliably done on POSIX.
But I believe correct file system that supports transactions will make it
possible to do reliably on POSIX too.

Then I believe that having a small chance of overwriting file just created
at exactly the same moment on a POSIX is a small price to pay for function
that does safety check before rename on a platform that doesn't have such
functionality at all. If you need this functionality - you will still do
'if exists ... rename' and the TOCTTOU race will affect you. So, the only
exit is to place a little sign "in some extreme cases Linux suffers from
TOCTTOU problem when renaming files without overwriting, so keep that in
mind".

BUT let me remind you that this bug is about "Atomic rename" which should
rollback in case of errors.
msg150193 - (view) Author: Antoine Pitrou (pitrou) * (Python committer) Date: 2011-12-23 19:35
> os.rename(overwrite=False) by default will do less harm than the opposite,

Disagreed.

> Then I believe that having a small chance of overwriting file just created
> at exactly the same moment on a POSIX is a small price to pay for function
> that does safety check before rename on a platform that doesn't have such
> functionality at all.

Disagreed.
If you need the functionality, it's *one* additional line of code. Not
every trivial function deserves to be in the stdlib.
msg150194 - (view) Author: anatoly techtonik (techtonik) Date: 2011-12-23 19:51
On Fri, Dec 23, 2011 at 10:35 PM, Antoine Pitrou <report@bugs.python.org>wrote:

> > os.rename(overwrite=False) by default will do less harm than the
> opposite,
>
> Disagreed.
>

Fine. No arguments == no consensus.

> > Then I believe that having a small chance of overwriting file just
> created
> > at exactly the same moment on a POSIX is a small price to pay for
> function
> > that does safety check before rename on a platform that doesn't have such
> > functionality at all.
>
> Disagreed.
> If you need the functionality, it's *one* additional line of code. Not
> every trivial function deserves to be in the stdlib.

As a Windows programmer I am quite surprised to read this thread with
information that on Linux os.rename() overwrites files without questions,
so as I Windows programmer I want os.rename() to stop that. I always guard
my code against accidental rewrite by catching the exception. EAFP and all
that stuff. But there is no way I can ask forgiveness when files are
already overwritten.
msg150195 - (view) Author: R. David Murray (r.david.murray) * (Python committer) Date: 2011-12-23 20:04
So maybe my warning idea isn't such a bad idea :)

As a unix programmer, I was very surprised to read in this thread that Windows doesn't overwrite the file on rename.  As a unix programmer, I don't check for errors on a rename, because I expect it to just work.  I'd like the windows rename call to stop throwing errors if the file exists, it breaks my programs if they run on windows.

(Actually, very few of my programs ever get run on Windows, but you get the idea.)

Thus, the only possible course is to maintain backward compatibility, and allow the programmers who care to specify the desired behavior.  Since one of the important aspects of 'rename' in unix programmers' minds is that it is atomic, a race condition is not acceptable, therefore overwrite=False is not an acceptable option for os.rename.
msg150196 - (view) Author: Antoine Pitrou (pitrou) * (Python committer) Date: 2011-12-23 20:09
> As a Windows programmer I am quite surprised to read this thread with
> information that on Linux os.rename() overwrites files without questions,
> so as I Windows programmer I want os.rename() to stop that.

As a Windows programmer, you are not really qualified to criticize the
behaviour of Unix systems.
As a Linux programmer, I don't want to see the default behaviour
changed.

> No arguments == no consensus.

We don't strive to achieve consensus. Agreement among the majority of
core developers is enough, and you aren't part of the population anyway.
msg152019 - (view) Author: Antoine Pitrou (pitrou) * (Python committer) Date: 2012-01-26 15:46
Here is a patch adding os.replace().
msg152348 - (view) Author: Roundup Robot (python-dev) Date: 2012-01-30 21:11
New changeset 80ddbd822227 by Antoine Pitrou in branch 'default':
Issue #8828: Add new function os.replace(), for cross-platform renaming with overwriting.
http://hg.python.org/cpython/rev/80ddbd822227
msg152349 - (view) Author: Antoine Pitrou (pitrou) * (Python committer) Date: 2012-01-30 21:13
os.replace() committed in 3.3!
History
Date User Action Args
2012-01-30 21:13:07pitrousetstatus: open -> closed
resolution: fixed
messages: + msg152349

stage: patch review -> resolved
2012-01-30 21:11:21python-devsetnosy: + python-dev
messages: + msg152348
2012-01-26 15:46:44pitrousetfiles: + osreplace.patch
keywords: + patch
messages: + msg152019

stage: needs patch -> patch review
2011-12-23 20:09:40pitrousetmessages: + msg150196
2011-12-23 20:04:27r.david.murraysetmessages: + msg150195
2011-12-23 19:51:11techtoniksetmessages: + msg150194
2011-12-23 19:35:54pitrousetmessages: + msg150193
2011-12-23 19:29:06techtoniksetmessages: + msg150192
2011-12-23 17:32:06neologixsetmessages: + msg150188
2011-12-23 17:26:03techtoniksetmessages: + msg150186
2011-12-23 16:46:50r.david.murraysetmessages: + msg150183
2011-12-23 16:30:55neologixsetmessages: + msg150182
2011-12-23 16:30:43pitrousetmessages: + msg150181
2011-12-23 16:22:24r.david.murraysetmessages: + msg150180
2011-12-23 16:15:13techtoniksetmessages: + msg150179
2011-12-23 16:08:46pitrousetmessages: + msg150177
2011-12-23 15:58:42techtoniksetmessages: + msg150176
2011-12-23 15:53:56neologixsetmessages: + msg150175
2011-12-23 15:39:06r.david.murraysetmessages: + msg150170
2011-12-23 15:28:00pitrousetmessages: + msg150168
2011-12-23 15:22:46r.david.murraysetmessages: + msg150166
2011-12-23 11:05:32pitrousetmessages: + msg150149
stage: needs patch
2011-10-24 16:40:27pitrousetmessages: + msg146307
2011-10-24 08:47:40pitrousetmessages: + msg146282
2011-10-24 06:56:17neologixsetmessages: + msg146280
2011-10-24 00:27:05pitrousetmessages: + msg146274
2011-10-24 00:23:12pitrousetmessages: + msg146273
2011-10-23 11:07:58neologixsetmessages: + msg146226
2011-09-14 06:53:41neologixsetnosy: + neologix
messages: + msg144011
2011-09-13 23:21:12hayposetmessages: + msg143995
2010-12-14 19:02:31r.david.murraysettype: enhancement
versions: + Python 3.3, - Python 3.2
2010-08-21 23:06:43eric.araujosetnosy: + eric.araujo
2010-06-10 09:36:17techtoniksetmessages: + msg107449
2010-06-09 22:52:34hayposetfiles: + atomic_move_file-windows.py

messages: + msg107434
2010-06-09 22:46:20hayposetmessages: + msg107433
2010-06-07 17:06:40techtoniksetmessages: + msg107269
2010-06-07 11:27:06hayposetmessages: + msg107264
2010-06-07 07:56:09techtoniksetnosy: + techtonik
messages: + msg107257
2010-06-04 15:42:08r.david.murraysetnosy: + r.david.murray
messages: + msg107070
2010-05-27 13:54:03draghuramsetnosy: + draghuram
2010-05-27 12:24:21hayposetmessages: + msg106609
2010-05-27 12:11:19pitrousetmessages: + msg106608
2010-05-27 10:51:44hayposetmessages: + msg106605
2010-05-27 10:44:19pitrousetnosy: + pitrou
messages: + msg106604
2010-05-27 10:32:39hayposetmessages: + msg106603
2010-05-27 10:10:24hayposetmessages: + msg106602
2010-05-27 10:03:17Trundlesetnosy: + Trundle
2010-05-27 09:58:53hayposetmessages: + msg106601
2010-05-27 09:47:23hayposetmessages: + msg106600
2010-05-27 09:46:19giampaolo.rodolasetnosy: + giampaolo.rodola
2010-05-27 09:45:57hayposetmessages: + msg106599
2010-05-27 09:41:11hayposetnosy: + tarek
2010-05-26 23:42:23haypolinkissue8604 dependencies
2010-05-26 23:41:40haypocreate