Re: Patch for "mv -s" option

[Brendan Byrd/SineSwiper]

Paul Eggert wrote:

> Brendan Byrd/SineSwiper <address@hidden> writes:
>
>
> > + All source file names must be absolute (starting with @samp{/}) unless the
> > + destination files are in the current directory.
>
> This seems like a serious limitation.  Can't you remove it, by using
> canonicalize_file_name say?

This limitation also exists in the "cp -s" command.  I copied that line 
from the "cp -s" docs.  Example:

address@hidden:~/tmp/a> mv -s b/f .
mv: `b/f': can make relative symbolic links only in current directory

address@hidden:~/tmp/a/b> cp -s f ..
cp: `../f': can make relative symbolic links only in current directory

So, it looks like it's expected behavior.  One annoying thing I found 
with that, is that it says that error message AFTER it's moved and tried 
to create a symlink with the file.  So you end up with the file already 
moved, and a broken symlink in tmp/a/b called [f -> ./f].

This may be related to the un-implemented (or rather un-ported from 
copy.c) "goto un_backup" routine.  At the very least, it should exit 
before the symlink call.  I'm going to try to fix the original problem 
by moving that current directory check to the beginning of the do_move sub.

BTW, can anybody explain the purpose of the backup function in the "mv" 
command?  I'd like to port the un_backup stuff, but I'm not quite sure 
how it works, or even if it's worth porting.  (Does anybody make backups 
during a move, even with so much error checking to ensure the file was 
moved?)

> Also, what happens with examples like "mv -s f .."?

Works just fine:

address@hidden:~/tmp/a/b> mv -s f ..
address@hidden:~/tmp/a/b> dir
total 0
lrwxrwxrwx    1 blkb     users           4 2004-11-19 00:14 f -> ../f

--
Brendan Byrd/SineSwiper <address@hidden>
Computer techie, Perl hacker, and all-purpose Internet guru
Resonator Software (http://www.ResonatorSoft.org/)