On Windows, if I do os.rename(old, new) where old is a file that is
in-use (e.g. python itself, or a dll that is loaded), I would expect
that an error would be raised (e.g. as when os.remove is called with
an in-use file). However, what happens is that a copy of the file is
made, and the old file
Tony Meyer wrote:
Is this the intended behaviour?
Sort-of. os.rename invokes the C library's rename, and does whatever
this does. It is expected that most platform's C libraries do what
the documentation says rename does, but platforms may vary in their
implementation of the C library, and from
[Tony Meyer]
Is this the intended behaviour?
[Martin v. Löwis]
Sort-of. os.rename invokes the C library's rename, and does whatever
this does. It is expected that most platform's C libraries do what
the documentation says rename does, but platforms may vary in their
implementation of the C
On Sat, 3 Dec 2005 22:32:22 +1300, Tony Meyer [EMAIL PROTECTED] wrote:
On Windows, if I do os.rename(old, new) where old is a file that is
in-use (e.g. python itself, or a dll that is loaded), I would expect
that an error would be raised (e.g. as when os.remove is called with
an in-use file).
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
On Sat, 03 Dec 2005 22:32:22 +1300, Tony Meyer wrote:
os.rename(sys.executable, d:\\python24.exe)
What happens if you specify a destination file on the same drive as the
source file ?
--
http://mail.python.org/mailman/listinfo/python-list
