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

[addady at active.co.il]

> > > If i recall correctly (i've not gone back to review that
> > > patch) that patch required whole-file transfers two avoid
> s/two/to/  #ick
> > > 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.
> >
> > You recall correctly.
> > It is not clear to me how using "whole-file" and still take advantage of
> > the rsync algorithm.
>
> You meant "how to use"?  The --whole-file option disables
> the rsync algorithm.
>
> > The idea of this patch seem to me very useful.
> > I'm plan to use it with the "rsyncable" gzip version
> > (http://svana.org/kleptog/rgzip.html).
> > 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

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


Addady