Proposed enhancements to rsync filters

[Wayne Davison]

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.

..wayne..