moving a file in a filesystem-independent way?

Fernando Perez fperez528 at yahoo.com
Fri Jan 31 15:18:05 EST 2003


Geoff Gerrietts wrote:

> Quoting Fernando Perez (fperez528 at yahoo.com):
>> 
>> This problem is nasty because the structure of unix filesystems is
>> such that things can change drastically from one machine to
>> anonther.  It's the first time that I find python being 'dumber'
>> than the plain shell commands.
>> 
>> But I'm sure it's me being dumb, not python :) So I'd appreciate any
>> enlightenment on why things are this way, or how I should go about
>> the problem.
> 
> As recently as 8 years ago, mv was that dumb, too. On some Unix
> systems, it still is.

Ah.  I've only been usling linux for just about 8-9 years, so I never 
noticed.

> The issue of transparency stands behind your problem. The functions in
> os.posix (and consequently available in os) are very close to the
> functions provided by the standard C library on your Linux system. The
> standard library's rename() function (man 2 rename) returns an error
> in the event that the source and destination are not on the same
> filesystem.
> 
> The convenience function you propose makes sense, but I'm not sure if
> replacing rename() is the right solution -- a new method called move
> might be preferable, to avoid confusion.

I totally agree that rename should reflect the underlying posix behavior 
faithfully.  But as others have pointed, this seems a reasonable enough 
request that shutils just grew a move() for python 2.3.  I'm just a bit 
surprised to read that it didn't exist before, I can hardly imagine being 
the first to complain about this one.

At any rate, thanks a lot to all who replied (Francois, Inyeol, Geoff,...).  
Informative and quick, as is the norm in c.l.py.  I'll work manually around 
the issue until I can safely assume that 2.3 is on all my machines (not for 
a while).

Cheers,

f.





More information about the Python-list mailing list