include/exclude bug in rsync 2.6.0/2.6.1pre1
bowman at math.ualberta.ca
Sat Apr 10 13:05:15 GMT 2004
> > 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:
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
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
> > 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
> > 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).
-- John Bowman
More information about the rsync