include/exclude bug in rsync 2.6.0/2.6.1pre1

[John Bowman]

> > and also fixes a bug that was introduced in 2.6.0 exclude/include
> > option that prevents included patterns in one list from overriding
> > previously excluded patterns from another.
> 
> This isn't a bug -- it was done as part of the exclude cleanup to fix
> some potential mishaps.  For instance, if a server has specified these
> include/exclude rules:
> 
> + /foo.c
> - /*.c
> 
> it was done that way to say "I'll let you copy foo.c, but no other .c
> files."  Not to say, "You must take foo.c whether you want it or not."
> Thus, an inclusion match in a list just means that the name avoids being
> excluded by that particular list.

With the scheme I proposed, the rule to accomplish this is straightforward:
- /*.c
+ /foo.c

If you decide later that you don't want foo.c, you can always tweak it
locally using --rsync-exclude (which works recursively, similar to .htaccess
files in Apache).

This is more consistent with the way most computer languages/shells work (and
also with the way most people think). If one says

a=1
a=2

one would expect the final value of a to be 2. Or if one says

mv a/*.c b/
mv b/foo.c a/

all a/*.c files except for foo.c should end up in directory b.

> 
> Yes, this means that if any of the 3 exclude lists tells rsync to
> exclude a file that it gets excluded.

Yes, that is the problem with the current scheme; there is no way to override
exclude entries from other lists. I want to specify general system-wide
rules with --exclude but (recursively) override them in local directories
(and perhaps further override these local rules in the subdirectories
contained within).

> > an entry at the end of the list should override a previous entry
> 
> Most definitely NOT.  The documented behavior has always been "first
> match wins."  To change this to "last match wins" would be incompatible
> with prior rsync versions.

I appreciate the backward compatability problem you face and can understand
your reluctance to change this. But as pointed out above, the current behaviour
is not what most people would expect. I generally opt for the policy of "no
surprises".

> > I would very much appreciate it if this patch were incorporated into the
> > next release of rsync
> 
> I'll massage it a bit and put it in the patches dir for now.  We'll
> consider it for the release after 2.6.1 (which is going to be more of
> a feature-adding release than this one).

Thanks,

-- John Bowman