On Fri, 2005-12-02 at 17:41 +0000, Manuel López-Ibáñez wrote: > I am sorry, the rsync algorithm needs to execute rsync on the server. > Since ftp does not allow executing remote programs (as ssh does), even > if there exists a rsync executable installed in the server and you have > permission to execute it, using ftp you cannot execute it. So your > command won't work and it will never be because it is impossible to > implement it by the very differences of what rsync does (executing a > remote rsync program) and how ftp works (just download files).
In my opinion, that's a perfect explanation. However, Marten is probably far from the only person who would love to use rsync over an FTP connection. Its flexibility has to surpass that of just about every tool that does support FTP. Yet there is the problem of not being able to run rsync on the other side. So let me suggest that someone make a hacked version of rsync that accesses a filesystem over FTP instead of a local filesystem. This shouldn't be too difficult since rsync already has a filesystem abstraction layer (do_stat, do_open, etc.). Then, one could do rsync over FTP by running both processes on the local machine. Of course, the send-the-differences algorithm would not be useful, but all of the other features would work. If someone has written a stable FTP virtual filesystem for FUSE or similar, one could achieve the same effect by doing a "local" rsync involving the virtual filesystem. Incidentally, a while ago on the list, people were doing essentially this but over NFS and wondered why the send-the-differences algorithm didn't seem to be reducing I/O. -- Matt McCutchen, ``hashproduct'' [EMAIL PROTECTED] -- http://hashproduct.metaesthetics.net/ -- To unsubscribe or change options: https://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html