Proposed enhancements to rsync filters
wayned at samba.org
Wed Dec 7 20:11:57 GMT 2005
On Tue, Dec 06, 2005 at 06:13:14PM -0500, Matt McCutchen wrote:
> "+ mydir//" would be equivalent to "+ mydir" "+ mydir/**".
Hmm. We do allow "**" to be empty in the pattern "+ **/foo" (matching
/foo). So really, "+ mydir/**" should be enough to also match "mydir/"
by itself. I don't see a downside to that change (since the rule would
currently be ineffective unless mydir was also included, its presence in
the rules indicates a desire to have that directory included).
> (2) Add a third sender behavior to "hide" and "show": "traverse" (T).
That might be better as a command-line option, which would withhold the
adding of all directories to the file-list until a non-directory
required them to be present. Perhaps --exclude-empty-dirs.
> S /foo/bar/wanted-tree-1//
> S /foo/baz/wanted-tree-2//
> T /**
That example would be better solved by using -R or --files-from. The
case where too many directories get sent is usually due to something
like "+ */", "+ *.zip", "- *". Your solution could handle that, but so
would a command-line option.
> (3) The "protect" (P) receiver behavior is a misnomer, since the
> receiver still allows a sender file to overwrite a protected file.
The docs specifically say that it only protects against deletion, but
"keep" may indeed have been a better word choice. One of the deciding
factors was that I wanted each set of opposite rules (in this case, risk
and protect) to be intuitively associated, and I'm not sure what I would
have chosen for an opposite of "keep" (though "risk" probably works OK).
> Add a new receiver behavior, "lock" (L). If the receiver is asked to
> change a locked file in any way or create a file at a locked path
> (i.e. if a file existed there it would be locked), the receiver
> complains and does nothing.
That sounds like a useful addition.
> (4) "Protect" and "lock" rules should accept a modifier specifying
> that it's OK to delete a protected or locked file because its parent
> is being deleted.
Another nice idea. The Subversion problem you mentioned recently came
up on the list, and this would provide a good way to solve this.
> I feel that "--backup" should automatically generate a filter "P *~"
> (or maybe "L *~"), where ~ stands for the backup suffix, to stop this
> from happening.
I've considered this in the past without being swayed, but am now coming
around to thinking that this would be an improvement.
> (2) Suppose "--backup" were changed so that, when rsync needs to
> delete a directory, it backs up the entire directory as a unit
A problem comes about if there have already been backed-up files from
that hierarchy in the backup area (the directory will already exist) and
the backup area might be on a different drive, so we'd need to support
the current algorithm for when the new algorithm failed. Thus, I think
I'll just leave it as it as it is.
> Before backing up a directory, should rsync scan it for locked or
> protected files?
Yes, if files are being protected (without your suggested parental-
delete modifier), they need to remain unaffected in the hierarchy.
More information about the rsync