Paul Rubin wrote: > Jeff Schwab <[EMAIL PROTECTED]> 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. -- http://mail.python.org/mailman/listinfo/python-list
