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