plain source -> encrypted destination: rsync + gpg

jw schultz jw at
Thu Jun 26 21:06:41 EST 2003

On Thu, Jun 26, 2003 at 10:42:35PM +1200, Martin Langhoff wrote:
> jw schultz wrote:
> >Stop thinking client and server.  Once the session is
> >initiated there is little difference.  Think instead sender
> >and receiver.
> Good advise. Have to rephrase myself, then ;)
> As I read the patch, it seems to be running an arbitrary command on the 
> receiver.
> I am thinking of running an arbitrary command on the server, when it is 
> preparing itself to open the file and start feeding data to the receiver 
> (to the socket, should I say?).
> Am I on the right track? Help/advise? Is it doable at all?

That sounds fairly doable.  I'm thinking what you would do
is to create a temporary file to match/send and delete it on
close.  Essentially wrap the applicable open and close ops.

If i recall correctly (i've not gone back to review that
patch) that patch required whole-file transfers two avoid
doing the operation twice per file.  If the filter is
deterministic and particularly if changes have minimal
cascade effect you may be able to still take advantage of
the rsync algorithm.

Actually given this and the fact that a compressed file
would be smaller it makes a bit more sense to do the filter
on the sender.

To answer your earlier question regarding a possible merge
it is very unlikely that this sort of patch would be
accepted into mainline of rsync 2.x.  If it is a clean patch
that looks to have wide use it could be included in the
patches directory but the maintainers could not be expected
to keep it up to date.

	J.W. Schultz            Pegasystems Technologies
	email address:		jw at

		Remember Cernan and Schmitt

More information about the rsync mailing list