plain source -> encrypted destination: rsync + gpg(--dest-filter patch)

jw schultz jw at
Fri Jun 27 00:33:43 EST 2003

On Thu, Jun 26, 2003 at 05:45:55PM +0200, addady at wrote:
[Lots of missing attribution maybe correctly reinserted]
[please don't remove attributions of quoted content]
> jw wrote:
> > addady at wrote:
> > > The idea of this patch seem to me very useful.
> > > I'm plan to use it with the "rsyncable" gzip version
> > > (
> > > The "whole-file" is not necessary is this case.  I think that the patch
> need
> > > to be modifiy so that
> > > whole-file will be a option.
> >
> > If the receiver does the filtering whole-file is necessary.
> > To show why i will describe what it takes if the receiver
> > does the filtering without whole-file assuming gzip is the
> > filter.
> This Idea is usefull only if the sender those the filtering

It is also useful the receiver does filtering without the
sender's knowledge.  In fact most of the requests for
compression filtering are for backup servers using rsyncd
with compression activated in the rsyncd.conf unbeknownst to
the client.

> > If the filtering is done on the sender.
> >
> > gzip file to temp.*
> >
> > match blocks or send whole gziped file to receiver.
> >
> > delete temp file.
> >
> > Observe the sender-side only requires a forward filter.
> >
> > *The temp file is needed because match and block
> > checksumming use memory mappings of the file so i don't
> > think it is capable of reading from a pipe.  Merging even
> > does seeks because matched blocks may be out of order.
> >
> > Whether the rsync algorithm is useful depends on the
> > determinism and change-cascade effects of the filter.
> > A ignore-size option would have to be created to deal with
> > filters that alter the file length.  The --checksum option
> > would be best not used as it would require every file be
> > filtered during flist generation and then changed files
> > filtered again for sending.
> Yes, files will be filter twice. But not every file, only the candidate for
> syncing
> base  on the modification time,  using --times-only  flag.
> Quote from Kyle Jones patch posting:
> "an rsync option --times-only so that rsync would consider
> only the modification time of the remote file when deciding
> whether to update it.  This is needed so that rsync would
> ignore the file size differences of compressed remote files."

Please not --times-only.  There are other factors you might
not be ignoring.  I'd prefer --ignore-size because that is
all you are doing with that option.

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

		Remember Cernan and Schmitt

More information about the rsync mailing list