It seems that the --dest-filter patch of Kyle Jones can help you.
Here is a link http://groups.google.com/groups?q=%22--dest-filter%22+group:mailing.unix.rsy nc+group:mailing.unix.rsync&hl=en&lr=&ie=UTF-8&group=mailing.unix.rsync&selm =b6f55s%24256q%241%40FreeBSD.csie.NCTU.edu.tw&rnum=1
I-n-t-e-r-e-s-t-i-n-g. I am still a bit confused as to why the compression happens at the server and not at the client.
In the case where the client starts the transaction to "push" files (or push changes, rather) to the untrusted server, running the tool on the remote server is self-defeating.
We are planning to use gpg for the purpose, so we could trust the server enough to run gpg with our public key. All the server needs is to use its own public key instead.
Is this going to be merged into HEAD? Are there any good reasons why for not running it on the client?
I have to admit, I am not familiar with the source. Browsing a cvs checkout of the HEAD, it seems that I should be looking at sender.c. There is exactly one instance of do_open() in send_files().
On the other hand, I don't know the protocol but if the pre-send filter changes the filesize in any way, we are toast. Or maybe not?
regards,
martin
-- To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html
