BUG: scp -r follows symlinks

[Edward S. Peschko]

On Mon, Jan 05, 2004 at 05:43:00PM -0800, Dan Kaminsky wrote:
> tar is _everywhere_.  In fact, tar works much, much more often than scp 
> does.

But tar is also inconsistant - eg. solaris tar and gnu tar are incompatible.
gnu tar for example takes leading slashes off of absolute pathed' files. 

And tar is suboptimal for the task. If I do a '-r' I can be guaranteed that 
the same logic is going to be performed for whether my argument to -r is a
file or directory.

If I am scp'ing recursively a file, I need to do a different command than a 
directory - because of the need to chdir into the directory I am going 
to scp. And I therefore need to 'test' the remote system to see whether
or not it *is* a file or directory.

And finally, tar doesn't work cleanly for something of the form:

scp -r user at host1:/directory1 user at host2:/directory2

Believe me, I know how messy this can get. I just spent the last couple of 
hours writing a perl wrapper around it. And it still doesn't approximate 
the efficiency of a true -r solution.

> rsync does not require an extra service when invoked as such:   rsync -e 
> ssh -r user at host:/path path

fair enough.. but it would still be much less of a pain to have this all bundled
into one command. Why should I maintain two?

> symlink syntax is notoriously messy.  It's rare that anything _but_ tar 
> can handle it correctly (I mean, that's the point -- it looks like a 
> normal file/dir).
> 

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.

Ed