BUG: scp -r follows symlinks

[Edward S. Peschko]

On Tue, Jan 06, 2004 at 04:13:07PM +0100, Christian Vogel wrote:
> Hi Edward,
> 
> On Mon, Jan 05, 2004 at 09:32:59PM -0800, Edward S. Peschko wrote:
> > Ok... duplicate the logic that tar has in determining what is a link. Or accept
> > a patch that does this. Or build in a tar interface, so that -r is implemented
> > in *terms* of tar. Or somesuch. All I know is right now, its not very user friendly,
> > and its not script friendly.
> 
> *besides* *that* *specific* *symlink-problem*: There are so many
> different behaviours one could expect in "cp" like commands that I would
> rather make it explicit by using a well understood tool like tar (or, my
> favourite, cpio).

Chris,

That's my point -

If a new flag, say -n, is implemented in scp in *terms* of tar, and moreover is 
made available by configure option (like say, xv can optionally use libjpeg), you could
say at configure-time:

./configure --use-tar <other options>

and have scp link with the tar library to support -n.

Furthermore, it is fully backwards compatible - how can it not be? 'scp -n' is not
workable right now. The only tricky part would be in supporting -n on local copies, but
that's straightforward - 'cp -r' already does the 'right thing' so -n is a no op. Or 
implement it in terms of cpio. In any case its a *new flag*; you can have it do what 
you want it to do.

I can't see how its in the interest of anybody to keep the tool suboptimal. I guess
I just don't understand your point of view.

Ed

(
ps - as for sftp, again, that's script-unfriendly. Any time you need to cat out to a 
file, or make a temporary file, or somesuch just to automate something you are causing
one more headache for the script maintainer in the form of cleanup.

And you are also causing one more inconsistancy: if I create a '-r' for sftp, and 
-r handles 'symlinks the right way', then people are rightly going to wonder why
that sftp and scp do things differently with the same flag. 

If you make it a different flag, and it does recursive copies, people are going to 
wonder why you made two similar flags with two separate functions.

And finally, if you use sftp for what I suggest, you *still* won't be able to 
do statements of the form

scp -r -n user at host1:/dir user at host2:/dir2

And you are still going to have to go through the process of linking with tar to get the
'right' results, so you've done 95% of the work anyways.
)


> Should we try to mimic this kind of behaviour in scp, sftp, rcp, ...?
> Should one rely on this behaviour in shell scripts (having to check via
> test -d before)? Or should one just use cpio -p in these cases, which has
> a well-defined behaviour, works with hardlinks, symlinks, ...

Fine, again, you could shoe-horn this behaviour into -n. Its your flag, you can do 
what you want with it. And you make the tool more effective in the process.