rsync - Nov 2003 - unexpected --exclude pattern behaviours with glob wildcards

Rsync version: rsync-2.5.6-3mdk (Mandrake 9.2)

I see from the CVS log that some of the following awkwardness may be
fixed (or at least different) in the next public release.  I'm looking
forward to that.  In the interim, here are some problems:

---------
Problem 1 - unexpected consequence of replacing / with **
---------

The following exclude works because the explicit slash causes a match
against the full pathname:

$ rsync -n -a -R -vv --exclude '2001_x10automation/announcement.txt' \
   public_html/oclug /tmp/ijunk
excluding file public_html/oclug/2001_x10automation/announcement.txt
   because of pattern 2001_x10automation/announcement.txt

Now replace the slash with the more general pattern '**'.  The following
exclude fails because the lack of any slash makes the match apply only
to last component:

$ rsync -n -a -R -vv --exclude '2001_x10automation**announcement.txt' \
   public_html/oclug /tmp/ijunk
public_html/oclug/2001_x10automation/announcement.txt

This is true to the documentation; but, it isn't what I expected.  If
I use a ** in a pattern it's because I *want* it to match the slashes!

---------
Problem 2 - unexpected consequence of replacing a character with '?'
---------

The following exclude works (note: no GLOB patterns):

$ rsync -n -a -R -vv --exclude '2001_x10automation/announcement.txt' \
   public_html/oclug /tmp/ijunk
excluding file public_html/oclug/2001_x10automation/announcement.txt
   because of pattern 2001_x10automation/announcement.txt

The following exclude fails (replace one char with a GLOB char):

$ rsync -n -a -R -vv --exclude '2001_x10automation/announcement.tx?' \
   public_html/oclug /tmp/ijunk
public_html/oclug/2001_x10automation/announcement.txt

I don't understand the above at all.  Adding a wildcard character to
a working exclude shouldn't cause it to fail.

Adding '**' to the front of the failing pattern causes it to start
working again.  Why?  This is really not how I expect it to work.

Keep up the good work - this is a fabulous tool.

-- 
-IAN!  Ian! D. Allen   Ottawa, Ontario, Canada
       EMail: idallen@idallen.ca   WWW: http://www.idallen.com/
       College professor via: http://teaching.idallen.com/
       Board Member, TeleCommunities CANADA  http://www.tc.ca/

On Mon, Nov 10, 2003 at 12:28:39PM -0500, Ian! D. Allen
wrote:
> I see from the CVS log that some of the following awkwardness may be
> fixed (or at least different) in the next public release.
Yes, there was quite a bit of bug-fixing in this area for the next
release.  The 2 problems you cited were among my list of bugs that
I targeted and fixed for the next release.
> If I use a ** in a pattern it's because I *want* it to match the
> slashes!
Precisely.  This is now assumed (and documented) in the CVS version.
> I don't understand the above at all.  Adding a wildcard character to
> a working exclude shouldn't cause it to fail.
Quite so.  This bug was happening because wildcard-containing strings
with an interior slash were not "floating" at the end of the path.
Thus, your string is treated as having a leading '/' if it has a
wildcard in it, which is why it suddenly failed to match when you added
the '?' to it.  This fix is also in CVS (along with several others).

Thanks for your bug report!

..wayne..