Bug 5043 - Qualified non-inherited filter rules may be ignored
Summary: Qualified non-inherited filter rules may be ignored
Alias: None
Product: rsync
Classification: Unclassified
Component: core (show other bugs)
Version: 2.6.9
Hardware: x64 Linux
: P3 normal (vote)
Target Milestone: ---
Assignee: Wayne Davison
QA Contact: Rsync QA Contact
Depends on:
Reported: 2007-10-25 20:17 UTC by wolfgang.mayer
Modified: 2007-10-26 11:58 UTC (History)
0 users

See Also:


Note You need to log in before you can comment on or make changes to this bug.
Description wolfgang.mayer 2007-10-25 20:17:35 UTC
It seems that under certain conditions, local filter rules where the
pattern is anchored with '/' to prevent rule propagation to sub-directories
leads to these rules being dropped entirely.

The following simplified example demonstrates the problem:

$ TESTDIR=/tmp/rsync-test
$ mkdir -p $TESTDIR/{root/{a/b,b/a/c},dst}
$ echo "- /a" > $TESTDIR/root/.rsync-filter

The following fails to exclude $TESTDIR/root/a, despite the per-directory
filter rule stating that sub-directory 'a' should not be considered:
$ cd $TESTDIR/dst
$ rsync -avvFFR $TESTDIR/root/ $TESTDIR/dst/
sending incremental file list
[sender] hiding file /tmp/rsync-test/root/.rsync-filter because of pattern .rsync-filter
delta-transmission disabled for local transfer or --whole-file
total: matches=0  hash_hits=0  false_alarms=0 data=0

Running rsync without '-R' works as expected, and changing into a directory
above $TESTDIR/root and using the relative path to $TESTDIR/root also seems
to work without problems.

We're running rsync version 2.6.9 protocol version 29, on Fedora7/x86_64
and CentOS5/{i686,x86_64}. The same behaviour appears in the latest version
from CVS [3.0.0pre2  protocol version 30.PR12].
Comment 1 Matt McCutchen 2007-10-25 21:07:59 UTC
I can reproduce the problem in the latest CVS rsync.  The problem appears to be that in rule_matches, rsync prepends an extra copy of the working directory to the rule pattern because the "name++;" on line 531 of exclude.c controverts the "*name != '/'" test on line 541.
Comment 2 Wayne Davison 2007-10-26 11:58:30 UTC
Thanks for the analysis, Matt.  I've fixed the bug in CVS.

I verified the fix using your test case, Wolfgang, so thanks for the detailed report!