Hello,
The behaviour described by Hein Roehrig is still reproducable using
current unstable ssh and the command sequence posted by Hein:
schabi@lunix:/tmp$ ssh -V
OpenSSH_3.5p1 Debian 1:3.5p1-5, SSH protocols 1.5/2.0, OpenSSL
0x0090701f
schabi@lunix:/tmp$ cd /tmp
schabi@lunix:/tmp$ mkdir t1
schabi@lunix:/tmp$ cd t1
schabi@lunix:/tmp/t1$ ln -s . t1
schabi@lunix:/tmp/t1$ cd /tmp
schabi@lunix:/tmp$ mkdir t2
schabi@lunix:/tmp$ scp -r t1 127.0.0.1:/tmp/t2
schabi@127.0.0.1's password:
t1/t1/t1/t1/t1/t1/t1/t1/t1/t1/t1/t1/t1/t1/t1/t1/t1/t1/t1/t1/t1/t1/t1/t1
/t1/t1/t1/t1/t1/t1/t1/t1/t1/t1/t1/t1/t1/t1/t1/t1/t1/t1: Too many levels
of symbolic links
I just stepped over it when scp'ing my home directory of the university
account to another machine for backup purposes: In the Gnome desktop
directory, there was a symlink backpointing to the home directory, and
so after some copying, my harddist was full (although there were over 2
Gigs free before, and my home only had about 130MB).
I'd wish that scp would recognize symlinks to files that it has already
copied, and then recreate the link on the target.
Alternatively, an option that recreates all symlinks would be useful.
Btw, tar and rsync both handle this case, and even mkisofs has an option
whether to follow symlinks...
Thanks,
Markus