plain source -> encrypted destination: rsync + gpg

[Martin Langhoff]

jw schultz wrote:

>>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.

I may try something this weekend.

> 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.

Agreed. I suspect that we migth be messing things up if the receiver has
any predefined idea of the filesize. Again, I am not versed in the
protocol, but aren't filesizes interchanged early with the filelist?

Does the receiving end use that info when receiving the file?

> 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.

_If_ I write a _clean_ patch and _if_ I can demonstrate its value, do I
get a chance?

There is certainly enough interest. I have found many posts about this
kind of feature related to rsync and unison. Because, let's say it
aloud, the replication abilities of rsync are excellent. You could take
the smarts of the protocol (the rolling CRC technique and sending of
deltas) away, and I'd still use it to replicate complex directory trees
with soft/hard links and other oddities.

Indeed, the fact that is used on the local filesystem speaks volumes.
Rsync is in many ways superior to cp.

kind regards,





martin