Bug 485 - scp doesn't preserve symbolic links
Summary: scp doesn't preserve symbolic links
Status: CLOSED WONTFIX
Alias: None
Product: Portable OpenSSH
Classification: Unclassified
Component: scp (show other bugs)
Version: -current
Hardware: All Linux
: P2 normal
Assignee: OpenSSH Bugzilla mailing list
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2003-02-07 02:13 AEDT by jsk29
Modified: 2003-06-06 02:03 AEST (History)
0 users

See Also:


Attachments
Make scp skip symlinks (464 bytes, patch)
2003-02-24 13:19 AEDT, Damien Miller
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description jsk29 2003-02-07 02:13:44 AEDT
I apologize if this has been reported in another bug report.  I couldn't find
it, though, which surprises me.  I think this bug must have bitten a lot of people.

scp does not follow symbolic links.  I consider this a bug.  I understand that
some people consider this a feature, since rcp behaved the same way.  However, I
also consider it a bug in rcp. :)  (Besides, what fraction of scp users actually
ever used rcp?  It must be very small.)

It is currently extremely easy to get scp locked in an loop.  I use scp to move
input and output files from my simulations all day long, and symbolic links are
present everywhere.  I have to play a lot of games with tar to get things to
work now.  That's totally barbaric. :)

Please, please, please fix this.  Include a backwards compatibility switch if
you like.  scp rocks, but this one little bug drives me nutty. :)

Thanks guys,
John
Comment 1 Markus Friedl 2003-02-07 07:51:37 AEDT
why don't you use sftp?

i think skipping links is an option, but copying not.
Comment 2 Damien Miller 2003-02-24 13:19:45 AEDT
Created attachment 238 [details]
Make scp skip symlinks

Like this...
Comment 3 jsk29 2003-02-24 14:20:01 AEDT
I don't use sftp because the semantics of scp is exactly what I need.

"cp -r" preserves symbolic links.  scp should behave identically.
Comment 4 Damien Miller 2003-06-04 23:28:13 AEST
no, scp behaves like Berkeley rcp - which has never copied links.
Comment 5 jsk29 2003-06-04 23:53:37 AEST
Is it really that painful to add a switch which makes it preserve links?  Do you
have any understanding of how much of a pain in the ass this "feature" of
disregarding the status of links can be?

You have a program that can easily lock itself into a loop.  This is a _problem_.

Scp is a godsend.  I'd really like to have my only problem with its use cleared up.

(My attitude is, since Berkeley rcp behaved this way, it was broken, too.  Fix
the bug.  Why adamantly adhere to the brokenness of an ancient program?)
Comment 6 Damien Miller 2003-06-04 23:58:25 AEST
the scp/rcp is 20+ years old and widely deployed - we don't have to option of
unilaterally changing it.

Use rsync, sftp or tar-over-ssh because scp isn't going to copy links. 

(you ignored the patch that I posted to fix the looping)
Comment 7 jsk29 2003-06-05 00:46:30 AEST
Sorry for not responding about the patch; I didn't ignore it.  It doesn't solve
the problem:  Information in a directory tree (a symbolic link) is disregarded
by scp.

Although I feel that the "correct" way to do this is to change the behavior of
scp to always respect links, another way is possible, which will retain
backwards  compatibility.  The switch "-R" is not in use by scp yet, and "cp -R"
means to copy a tree recursively, while respecting symbolic links.  Implementing
"-R" in scp will serve both purposes:  symbolic links will be respected, _and_
"scp -r" will work exactly the same way as it currently does.  No current
scripts will cease to function.

(I still think that rcp is a bad model for scp to mimic...  modelling off of the
behavior of cp would be much more user-friendly for most people, since they have
never used rcp.)
Comment 8 Ben Lindstrom 2003-06-05 00:54:59 AEST
You are currently preaching to the converted.  However, rcp over ssh (scp)
dates back to the original SSH Corp release.

The issue is you have to not only teach the client side the -R feature but you
have to teach the server side the -R.  So to add this feature would mean it 
would results in unexpected results for those going from OpenSSH 3.7 to any 
earlier release.
Comment 9 jsk29 2003-06-06 00:07:30 AEST
I'm happy to hear someone agrees! :)

I'm not so worried about incompatibilities w/ older servers.  It's perfectly
fine to issue an error if a server can't support an new operation a client would
like to perform.  Also, OpenSSH servers tend to get updated fairly often for
security reasons.  So, if a server can't support some operation, that probably
won't last for long.
Comment 10 Ben Lindstrom 2003-06-06 00:18:18 AEST
Still won't add it.  YOU may not care, but some of us do care.  I know people 
that are still running patched and customized 1.2.x SSH Corp servers that 
*CAN'T* upgrade them at this point.

Where I may agree with the fact rcp is brain dead.  I agree with djm@ that we 
should not be focusing on rcp/scp features and instead we should be focusing on 
sftp.  Which is RFC defined and much better generalized solution in most cases.
Comment 11 Damien Miller 2003-06-06 00:22:01 AEST
This discussion is academic - no option to copy symlinks is going to be added.
We may add a patch to stop following of symlinks though.

Even if we did have a desire to "extend" the rcp protocol, one must consider not
only interop against older version of OpenSSH, but also ssh.com and other free
and commercial servers (and dozens of Windows clients). With scp being specified
as "BSD rcp over ssh", a protocol lacking extensibility mechanisms or feature
negotiation, there is no chance of them all changing.

You may have more luck conviencing someone to make a scp-like commandline
interface to sftp - a protocol which does have the ability at protocol level to
transfer symlinks. That would be a separate bug.
Comment 12 jsk29 2003-06-06 02:03:34 AEST
Yeah, I thought about this more last night, and I think one possible solution is
to hack what I need together just using sftp.  Maybe someone someday will define
their own remote cp, without any concern for backwards compatibility w/ rcp, and
base it off of sftp.

Anyway, you are right, this is academic.  None of this will make any of my
scripts any cleaner any time soon.