Am Sat, 29 Apr 2017 20:38:24 +0100 schrieb lee <l...@yagibdah.de>: > Kai Krakow <hurikha...@gmail.com> writes: > > > Am Tue, 25 Apr 2017 15:29:18 +0100 > > schrieb lee <l...@yagibdah.de>: > > > >> since the usage of FTP seems to be declining, what is a replacement > >> which is at least as good as FTP? > >> > >> I'm aware that there's webdav, but that's very awkward to use and > >> missing features. > > > > If you want to sync files between two sites, try rsync. It is > > supported through ssh also. Plus, it's very fast also. > > Yes, I'm using it mostly for backups/copies. > > The problem is that ftp is ideal for the purpose, yet users find it > too difficult to use, and nobody uses it. So there must be something > else as good or better which is easier to use and which ppl do use.
Well, I don't see how FTP is declining, except that it is unencrypted. You can still use FTP with TLS handshaking, most sites should support it these days but almost none forces correct certificates because it is usually implemented wrong on the server side (by giving you ftp.yourdomain.tld as the hostname instead of ftp.hostingprovider.tld which the TLS cert has been issued for). That makes it rather pointless to use. In linux, lftp is one of the few FTP clients supporting TLS out-of-the-box by default, plus it forces correct certificates. But I found FTP being extra slow on small files, that's why I suggested to use rsync instead. That means, where you could use sftp (ssh+ftp), you can usually also use ssh+rsync which is faster. There's also the mirror command in lftp, which can be pretty fast, too, on incremental updates but still much slower than rsync. > I don't see how they would transfer files without ftp when ftp is the > ideal solution. You simply don't. FTP is still there and used. If you see something like "sftp" (ssh+ftp, not ftp+ssl which I would refer to as ftps), this is usually only ftp wrapped into ssh for security reasons. It just using ftp through a tunnel, but to the core it's the ftp protocol. In the end, it's not much different to scp, as ftp is really just only a special shell with some special commands to setup a file transfer channel that's not prone to interact with terminal escape sequences in whatever way those may be implemented, something that e.g. rzsz needs to work around. In the early BBS days, where you couldn't establish a second transfer channel like FTP does it using TCP, you had to send special escape sequences to put the terminal into file transfer mode, and then send the file. By that time, you used rzsz from the remote shell to initiate a file transfer. This is more the idea of how scp implements a file transfer behind the scenes. FTP also added some nice features like site-to-site transfers where the data endpoints both are on remote sites, and your local site only is the control channel. This directly transfers data from one remote site to another without going through your local connection (which may be slow due to the dial-up nature of most customer internet connections). Also, FTP is able to stream multiple files in a single connection for transferring many small files, by using tar as the transport protocol, thus reducing the overhead of establishing a new connection per file. Apparently, I know only few clients that support that, and even fewer servers which that would with. FTP can be pretty powerful, as you see. It's just victim of its poor implementation in most FTP clients that makes you feel it's mostly declined. If wrapped into a more secure tunnel (TLS, ssh), FTP is still a very good choice for transferring files, tho not the most efficient. Depending on your use case, you get away much better using more efficient protocols like rsync. -- Regards, Kai Replies to list-only preferred.
