DSL link aggregation?

[Jeffrey Watts]

On Sat, May 10, 2008 at 4:58 AM, Christofer C. Bell
<christofer.c.bell at gmail.com> wrote:
>
> I agree with you completely, and believe it or not, there are
> commercial applications that support sftp yet do not support scp (as
> hard as that is to believe).  The particular application we're
> interacting with using sftp simply does not support use of scp.  It
> supports sftp reasonably well.  How that works internally, I have no
> idea, but scp is a no go.  This is proprietary SSH software running on
> a server owned by a service vendor that we have no control over.

In our case Chris, our app uses a wrapper around common FTP commands,
and uses FTP to execute them.  Some of those commands are easily
ported to SFTP (put, get, etc).  However others simply do not work
(like 'dir').  We can port them to use SSH instead, but given that the
current script uses FTP to simply save the 'dir' to a text file
locally means we would need to rewrite the script to do those
functions differently.

Obviously that's not terribly hard to do, but it's stupid that we'd
have to do it.  The fact is that SFTP doesn't support many common
functions of the FTP RFC standard, and for others it uses incompatible
command syntax.  This obviously isn't a "drop in" replacement like it
should be.  After all, SSH/SCP has many features enabling it to be a
"drop in" replacement for rsh/rcp.  There's no reason it couldn't do
the same for FTP.

Again, I'm not saying it's "bad".  However, it's not "superior".  It's
clearly not a "great" implementation of FTP.  It's a very SECURE
implementation, and it's capable of doing the majority of FTP tasks.
But for the rest, and for non-interactive use, it's deficient.  I'm
sure in time it will be better, but it's not "superior".

Jeffrey.

-- 

"He that would make his own liberty secure must guard even his enemy
from oppression; for if he violates this duty he establishes a
precedent that will reach to himself." -- Thomas Paine