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. -- To unsubscribe or change options: https://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html
