ftp recursively

[Jeff Schwab]

Paul Rubin wrote:
> Jeff Schwab <jeff at schwabcenter.com> writes:
>> ftping it as a flat file, and untarring it on the other side.  Of
>> course, the motivation wasn't just to get the files from point A to
>> point B using Unix (which I already know how to do), but to take
>> advantage of an opportunity to learn some Python; next time, I'll try
>> the ftpmirror.py script if it's generic enough, or ftplib if there are
>> more specific requirements.
> 
> I see, that wasn't clear in your original post.  You should look at
> the os.walk function if you want to know how to traverse a directory
> tree (maybe you are already doing this).

I thought os.walk was for locally mounted directories...  How is it 
relevant on remote filesystems?

> Also, for security reasons,
> it's getting somewhat uncommon, and is generally not a good idea to
> run an ftpd these days, even on a LAN.  It's more usual these days
> to transfer all files by rcp or rsync tunnelled through ssh.

Don't shoot the messenger, but you're severely confused here.  Whether 
you're using ftp, rcp, or rsync is a completely separate issue to 
whether you're running over ssl (which I assume you meant by ssh).

FTP is a work-horse protocol for transferring files.  It's going to be 
with us for a long, long time.  There are various clients and servers 
built on it, including the traditional ftp command-line tools on Unix 
and Windows.

rcp is a very simple tool for copying files from one (potentially 
remote) place to another.  The point of rcp is that its interface is 
similar to cp, so the flags are easy to remember.  Modern Unix and Linux 
systems usually include secure versions of both ftp and rcp, called sftp 
and scp, respectively.

The point of rsync is to keep a local directory tree in sync with a 
remote one, by transferring only change-sets that are conceptually 
similar to patches.  If you're only transferring files once, there's no 
particular benefit (AFAIK) to using rsync rather than some kind of 
recursive ftp.