This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

classification
Title: os.rename transparent handling of cross-filesystem issues
Type: enhancement Stage:
Components: Library (Lib) Versions:
process
Status: closed Resolution: later
Dependencies: Superseder:
Assigned To: fdrake Nosy List: fdrake, gvanrossum, jepler, jhylton, nobody, tibi
Priority: low Keywords:

Created on 2000-08-19 17:09 by anonymous, last changed 2022-04-10 16:02 by admin. This issue is now closed.

Messages (8)
msg1063 - (view) Author: Nobody/Anonymous (nobody) Date: 2000-08-19 17:09
On some systems (specifically, Linux), the rename system call will throw
an EXDEV error if rename is used across filesystems.  It would be convenient for the user if os.rename were extended to handle this transparently (like most mv commands do).

The benefits of this. . .getting rid of code like the following:

try:
    os.rename('ff','/tmp/ff')
except:
    open('/tmp/ff','w').write(open('ff','r').read())
    os.unlink('ff')

Actually, the real benefit is that code (written by morons like myself) using os.rename will continue to work even after the administrator moves the target directory to another filesystem.

I took a quick look at posixmodule.c.  A quick hack changes posix_2str's
signature to the following:

PyObject *args
char *format
int (*func)(const char*, const char *)
int (*special_handler)(const char *, const char *)

and the inner function to:

if (res != 0)
    if ((! special_handler) || (*special_handler)(path1,path2))
         return posix_error()

Of course, then a smart copy routine (includes an unlink step).  The most unclear thing at this point is what to do with the errno.  Would a failure in
the errorhandler report the original errno or its own errno???

Personally, a more general solution would allow the user (python-level) to optionally pass in *their own* error handling function/method.


msg1064 - (view) Author: Jeremy Hylton (jhylton) (Python triager) Date: 2000-08-25 14:44
revisit this after 2.0
msg1065 - (view) Author: Jeremy Hylton (jhylton) (Python triager) Date: 2000-09-07 22:05
Please do triage on this bug.
msg1066 - (view) Author: Fred Drake (fdrake) (Python committer) Date: 2000-09-15 20:01
Moved to PEP 42 as a feature request for a post-2.0 version of Python.
msg1067 - (view) Author: Guido van Rossum (gvanrossum) * (Python committer) Date: 2000-10-30 18:43
Copying files (and directories) properly is a very platform specific task -- there are lots of pitfalls that the copying code has to watch out for, e.g. copying files with "holes", properly copying all metadata, copying special files... I think that the os.rename() call is not the proper place to implement all this. But it's a useful feature nevertheless, and could perhaps be accommodated by a higher level function in the shutil module (which has the basic copying primitives).
msg1068 - (view) Author: Nobody/Anonymous (nobody) Date: 2002-03-08 17:03
Logged In: NO 

also unix weenies expect rename() to be atomic. making
it non-atomic can break lots of code that is carefully
crafted to survive nfs, or do locking with rename(), etc.
msg1069 - (view) Author: Thiébaut Champenier (tibi) Date: 2003-12-09 12:34
Logged In: YES 
user_id=25413

Since Python 2.3 the shutil module has a move function that 
implements this functionality.
msg1070 - (view) Author: Jeff Epler (jepler) Date: 2004-01-19 13:33
Logged In: YES 
user_id=2772

I saw this item in PEP42 and I'd also like to be on the
record against making os.rename() do fancy stuff.  If you
want shutil.move, you know where to find it.  As "nobody"
mentions, we unix people know exactly what rename(2) does,
and we want os.rename() to be a thin wrapper over it.
History
Date User Action Args
2022-04-10 16:02:18adminsetgithub: 32961
2000-08-19 17:09:35anonymouscreate