[patch] add "--ignore" option

[Matthew Kirkwood]

On Fri, 4 Feb 2005, Wayne Davison wrote:

> > >     -f "-s *.no_send" -f "-r *.no_delete" -f "- *.no_send+no_delete"
> >
> > Does that give any additional useful behaviour?
>
> Sure.  Having a rule be server-side only allows you to mark just some of
> the rules with a --delete-excluded behavior and make it the default when
> --delete is specified.

I meant over and above what my patch did.  Certainly it looks
to fit in better with the existing code.  I was just trying to
figure out whether this has other useful semantics.

[..]
> The reason for wanting this as a filter syntax is that filter rules are
> a superset of all possible ways to pattern match files.  Now that the
> filter option is present, I don't really want to see other new pattern-
> matching options added, so I would choose to omit the --ignore-from and
> --ignore.

Okey dokey.  It's the functionality I'm after really.

> > Additionally, isn't it the case that, until now, the sender never
> > needed to pass options to the receiver?
>
> If by options you mean include/exclude patterns, rsync has a way to send
> the excludes to the correct side of the transfer where they are needed.

I thought there might be one, but couldn't find it.

> (FYI, this is one area where your patch was deficient because it would
> only work if the user were pulling files -- if the user pushed files and
> specified --delete-excluded, no ignore patterns would have been sent to
> the remote receiving side.)

Well it worked for pushing over rsh transport (because I made
it pass the --ignore options opwards), but you're right that
it wouldn't be any use with rscyn in daemon mode.

> It is arguable if the receiver-side exclude should be ignored by
> --delete-excluded or not.  On the one hand, with the ability to turn any
> rule into a server-side rule, --delete-excluded behavior can be applied
> to any rule without specifying the option, so perhaps --delete-excluded
> should be made to ignore all filter rules, including "protect" rules.
> I have chosen to err on the side of safety and made it so that the
> --delete-excluded option only affects normal +/- rules.

That sounds pretty sensible to me.

> One other comment on your implementation: I don't think that we need a
> 3-state return from the exclude functions.  I think a better approach is
> to simply remove rules that don't apply to the current side.  So, to
> protect files from deletion without affecting the sending of files,
> rsync would simply need to remove the receiver-side rules from (or not
> transfer them to) the sending side.  This does mean that any "+" rules
> that were added to override receiver-side "-" rules would also need to
> be marked as receiver-only rules.

That sounds better.  I just wasn't sure I could catch all the
relevant cases otherwise.

> I've appended a patch that applies to the latest CVS source and
> implements the idioms I mentioned above.  It has been minimally tested.
[..]
> Let me know what you think.  Feel free to suggest alternatives if you
> think something should be done a better way.

It looks good to me.  I'll give it a try and let you know, but
I for one would be delighted to see this functionality in a
full release of rsync.

Thank you very much!

Matthew.