(fwd from uke@jeremy.org) thanks and patch

[Dave Dykstra]

On Thu, Mar 21, 2002 at 09:42:21AM -0800, jeremy bornstein wrote:
> On Thu, Mar 21, 2002 at 11:24:07AM -0600, Dave Dykstra wrote:
> > Oh, I see, you want to use your new --date-only option on the first pass
> > when you're determining which files to transfer, before you encrypt them.
> 
> Yes!
> 
> 
> > I guess that makes sense; I can't think of another easy to do what you want
> > to do.  Pretty obscure case though.
> 
> Obscure now, but I expect not forever.
> 
> If you consider it desirable for rsync to be able to do this task
> (encrypted backups on untrusted servers) all by itself, all it needs
> in addition to the --date-only option is the ability to accept a
> user-specified filter for each file to be transferred.  If I were to
> make a patch for that, I don't suppose you'd want it?

I don't know, I think it would depend on the implementation.  There might
be a number of uses that people could put it to.  The thing that I don't
like about it is that for most uses I can think of (compression is another
example) it won't be able to use the rsync rolling checksum algorithm,
which is mostly what people think of when they think of rsync.  It's true
that a lot of people end up using rsync just for its ability to recurse
down two directory structures and identify differences, however, so they
might be happy with it.  I would think the option would default to
--no-whole-file and imply your --date-only functionality even if we don't
have the option.

(If we did want --date-only functionality as a separate option I think it
should be called --times-only to go along with --ignore-times).


> It'd still need an encrypting filter, but that's essentially a one
> line sample that could be included in the docs.  (For symmetric
> encryption anyway.)

- Dave