moving a file in a filesystem-independent way?

Fernando Perez fperez528 at yahoo.com
Thu Jan 30 18:29:34 EST 2003


Hi all,

I've stumped myself today with a seemingly silly problem, and I'd like to 
hear a bit from the experts.

I need to move a file from A to B, under Linux. Simple enough task, use 
os.rename(A,B).  Right? 

Wrong.

Depending on whether A and B are located on the same filesystem or not, the 
call may fail with a nice 

OSError: [Errno 18] Invalid cross-device link

exception.  I googled around, and found that the best answer seems to be: 
'under certain versions of unix, to move a file do a manual copy and then 
unlink the file'.  This is just silly.  If 'mv' can work around filesystem 
issues, why can't we have a simple os.move() command which does the same?

I know, I can either just call mv myself or trap the above exception and 
then do a copy/delete, or just do a copy/delete from the get-go and live 
with the additional expense.  All these solutions look butt-ugly to me.

At the shell, I just type 'mv A B'. A cheap relink will be done if there's 
no filesystem boundary to cross, and a copy will be performed if necessary.  
But _I_ don't have to worry about that kind of low-level detail.

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.

Thanks,

f.




More information about the Python-list mailing list