[conspire] FileZilla isn't a file manager (but you can use it as one) (was: FTP)

[Rick Moen]

Quoting Paul Zander (paulz at ieee.org):

>  To clarify,  what I need to do is move individual files or whole trees between different computers.  The first usage was to backup files from machine A to machine B.  Then after doing an install on A, copy all of the files from B back to A.  Both machine have Filezilla, but it took some fussing around to get things working.  "A", with the new install needed an ftp daemon so I could initiate the transfer on B.  Running Filezilla on A wouldn't connect, until (much later) I remembered that B had a firewall.

The ftp protocol is problematic for firewalls on account of how it
connects, which is one of the reasons it's been little used for about
the last 20 years.

> Moving files within a particular system, I would either use mv or cp or whatever GUI file program was installed.  I've usually be OK with the default that comes with the installation.  
> So, I will re-phrase my earlier question.  What are suggested tools to move files and/or whole trees between computers?   I like the Filezilla GUI.  Not all of my computers run Linux

First, I have a FAQ about how to move file trees around, both within a
host (computer) and between hosts.  _However_, that FAQ doesn't cover
graphical tools,

"Copying Directory Trees" on http://linuxmafia.com/faq/Admin/

A good basic way of copying files is

    rsync -avz olddirectory/ [host:]newdirectory/

If copying _within_ a host, you'd omit the 'z' because it's foolish to
gzip-compress source files into RAM and then immediately gunzip
decompress them to write them out again.  The gzip compresion makes
sense only if it saves transmission time accross a network link.

Page goes on to partially satisfy our resident edge-case fanatics with
small improvements on that recipe.

rsync (and gzip/gunzip) most certainly exists for MS-Windows.  Because
they're open source.

You want a nice cross-platform GUI tool for cross-host file management,
and I have no problem of any kind with your preference.  I just don't
really know the field.

But you already have one possible:  FileZilla.  It can connect to a
remote host whose ssh daemon offers sftp access.  All ssh daemons do,
these days.  There are a whole bunch of ssh server-side implementations
for MS-Windows, too, even open source ones.

Catalogue here, organised by OS:[1]
http://linuxmafia.com/ssh/



Or, of course, you can support FileZilla's remote file-management access
by running an ftpd on the remote host.  Which means among other things
firewall headaches.  (Diehards say you deal with that by initiating the
ftp connection in 'passive ftp mode'.  I'm not even going to go further
into that.  Look it up, if curious.)

This page purports to cover remote file-management tools for MS-Windows
and Linux.  Author is a bit of a proprietary-mindset idiot, i.e.,
apparently is clueless about which codebases discussed are open source
vs. proprietary, and says only which ones can be acquired free of
charge:

https://www.webservertalk.com/best-ftp-and-sftp-clients



For the record, I really cannot understand what insisting on a graphical
tool gets you over just typing 'rsync -avz filetree linuxmafia.com:/tmp'
It's dead-simple, logical, and Just Works.[tm]  But OTOH, it's always
cool to like what you like because you like it.


[1] I made the ancestor of that page around 1996 when some guys on the
UC Santa Cruz LUG mailing list were talking about using telnet to 
remote-login around campus, and I replied with the polite version of 
"WTF?  Don't you know that's a security disaster, especially on a campus
wide-area network?  Why haven't you upgraded to ssh'  The guy responded
that he _couldn't_ use ssh, because a couple of the machines involved
ran DEC's OpenVMS.  Less than 60 seconds of Web-searching found two
_complete, open source_ server + client ports of ssh to OpenVMS.  So, I
started the page, out of disbelief that anyone would blow up their
security just because they never bothered to look for an ssh
implementation on an obscure OS platform, and spent a day documenting in
one place _all_ implementations of ssh on _all_ OS platforms, so that
next time I could kill that error instantly.