[patch] add "--ignore" option
matthew at hairy.beasts.org
Mon Feb 7 12:24:35 GMT 2005
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
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!
More information about the rsync