BUG: scp -r follows symlinks

[Dan Kaminsky]

tar is _everywhere_.  In fact, tar works much, much more often than scp 
does.

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

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).

--Dan




Edward S. Peschko wrote:

>hey all
>
>'scp -r ' follows symlinks. IMO this is a bug and should be changed - it:
>
>	a) hampers the use of scp. As it stands, I cannot use 'scp -r' because of this 
>       behavior. If someone links to '/', or if I hit a recursive symlink, I'm screwed.
>
>	b) It is inconsistant with cp. When you 'cp -r' on a file, it does NOT follow the 
>	   symlink. When you scp -r on a file, you *do*.
>
>	   And since scp is implemented in terms of cp (for local copies) this leads to 
>	   one use of scp preserving links, and another by making files out of them! This 
>	   is unintuitive and wrong.
>
>Please change this if it already is not changed - or indicate that a patch could be 
>accepted to change it. I am aware of the alternatives, such as tar and rsync. However,
>using tar requires an extra binary to be installed on a remote or local machine, and rsync
>requires an extra program to maintain, and an extra service to run(?). 
>
>And I don't want an extra dependency just to shore up a deficiency in an otherwise useful
>tool.
>
>Ed
>
>(ps - if people *don't* consider this a bug, then I'd appreciate someone telling me
>why. Just from googling, I've seen people complain about this up and down, causing 
>everything from GB of mistransfer to clogged traffic.
>)
>
>	   
>	   
>
>
>
>
>
>
>
>_______________________________________________
>openssh-unix-dev mailing list
>openssh-unix-dev at mindrot.org
>http://www.mindrot.org/mailman/listinfo/openssh-unix-dev
>  
>