Add modifiers for "show" filters that affect the file-list attributes of matching files. I propose this syntax:
- p(CHMOD-TWEAKS) : apply the CHMOD-TWEAKS like the --chmod option (overloaded with "perishable")
- o(USER) : set the user owner to USER
- g(GROUP) : set the group owner to GROUP
Issues to be considered:
- Interaction with --chmod, --chown, --usermap, --groupmap options
- Per-dir merge files become more powerful, so copying from an untrusted source with a per-dir merge rule becomes more dangerous. Do we care?
I am hoping to use this enhancement in the build process of my Web site. I have all the content in a "build tree" with makefiles to generate pages from a template. Then I call rsync with a bunch of filters to mirror a subset of the build tree to the Web server's document root. Different areas of the document root need different permissions: almost everything is 755/644, but as one notable exception, the /private dir is 711. I applied the desired permissions manually, but I want to make sure they don't get messed up. With this enhancement, I could add p(...) modifiers to the rsync filters to have it apply the permissions automatically on every build. For example:
rsync -rltp --filter='Sp(u=rwX,go=X) /private' --filter='Sp(u=rwX,go=rX) *' \
More generally, this enhancement could be used to implement any "make install"-like step with a single rsync run, which I feel would be a significant advance over install(1). With --delete-missing-args, "make uninstall" could probably be implemented as well.
I put a draft implementation in branch wip/filter-attrs of my repository. It works in some simple tests, but it needs some polishing and documentation before it could go into the main rsync.
I have polished the implementation a bit and split it into well-described commits. Wayne, please consider this for the main rsync or a maintained patch.
Note: I found that I couldn't actually overload the permissions modifier with the perishable "p" as proposed in comment #0 because a merge rule needs to be able to specify a default for both modifiers. Thus, I used "m" instead.
Thanks for the patch -- it looks good. I've worked a bit on getting it integrated into 3.1.0dev, and will try to finish it off soon.
Matt: I've added your various foundational patches plus some changes of my own, and then regenerated your final commit as a patch:
I'm thinking that, before I apply this patch, I would like some way to allow users to avoid unintended chown/chmod items in the merge files. One possible solution:
Add a trust (t) modifier for the merge-file filter rules that will mark the file as trusted. Any chown/chmod rules that are found in a non-trusted file would output a warning and skip the rule. Any merge-file rule (per-dir or not) defaults to having untrusted rules unless it is marked as trusted (even if it comes from a trusted source).
All command-line filter options would get processed with the internal "trusted-source" flag, so direct-on-the-command-line chown/chmod filter rules would all work.