On Sat, May 10, 2008 at 4:58 AM, Christofer C. Bell christofer.c.bell@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.