Debian Bug report logs - #59829
libc6: [PATCH] fnmatch() behaves oddly with *s and FNM_LEADING_DIR

Package: libc6; Maintainer for libc6 is GNU Libc Maintainers <debian-glibc@lists.debian.org>; Source for libc6 is src:glibc (PTS, buildd, popcon).

Reported by: Ryan Tracey <ryant@thawte.com>

Date: Tue, 7 Mar 2000 12:18:01 UTC

Severity: fixed

Done: Ben Collins <bcollins@debian.org>

Bug is archived. No further changes may be made.

Forwarded to libc-alpha@sourceware.cygnus.com

Toggle useless messages

View this report as an mbox folder, status mbox, maintainer mbox

Report forwarded to debian-bugs-dist@lists.debian.org, Bdale Garbee <bdale@gag.com>:
Bug#59829; Package tar. (full text, mbox, link).

Acknowledgement sent to Ryan Tracey <ryant@thawte.com>:
New Bug report received and forwarded. Copy sent to Bdale Garbee <bdale@gag.com>. (full text, mbox, link).

Message #5 received at submit@bugs.debian.org (full text, mbox, reply):

Package: tar
Version: 1.13.17-1

Tar no longer excludes the files and directories that previous versions
used to exclude (sorry, I have no idea with which version the change
occurred, but it was within the past month or so). For example, to
exclude all the MS Frontpage extensions files and directories in the
'webspace' directory tree, I used to do this:

	tar xcf /var/tmp/website.tgz --exclude=_\* webspace\

This used to exclude all the _vti_cnf/ and _private/ directories that
don't need to be on the main website.

I understand that there have been some changes in the way that tar
handles the exclude patterns, but there doesn't seem to be any pattern
that matches any directory that begins with the underscore character.
I've tried:

--exclude '_*'
--exclude '/_*'
etc..

This kind of file always ends up in the archive:
"webspace/synthesis/_vti_cnf/contents.html"
 
I am using Debian 2.2 with kernel 2.2.13 and libc 2.1.3-2.

Any help would be appreciated.

Thanks and regards,
Ryan

Information forwarded to debian-bugs-dist@lists.debian.org, Bdale Garbee <bdale@gag.com>:
Bug#59829; Package tar. (full text, mbox, link).

Acknowledgement sent to Colin Watson <cjw44@flatline.org.uk>:
Extra info received and forwarded to list. Copy sent to Bdale Garbee <bdale@gag.com>. (full text, mbox, link).

Message #10 received at 59829@bugs.debian.org (full text, mbox, reply):

reassign 59829 libc6
thanks

[Sorry for the length of this mail. Wildcards are always fiddly to
analyse.]

Ryan Tracey <ryant@thawte.com> wrote:
> Tar no longer excludes the files and directories that previous versions
> used to exclude (sorry, I have no idea with which version the change
> occurred, but it was within the past month or so). For example, to
> exclude all the MS Frontpage extensions files and directories in the
> 'webspace' directory tree, I used to do this:
> 
>         tar xcf /var/tmp/website.tgz --exclude=_\* webspace\
> 
> This used to exclude all the _vti_cnf/ and _private/ directories that
> don't need to be on the main website.

tar checks whether a name is excluded by using the libc function
fnmatch() with FNM_FILE_NAME and FNM_LEADING_DIR. With these flags, a
pattern like "_*" matches a string that contains something matching "_*"
and containing no slashes, followed by a string containing exactly one
slash: that is, the pattern is matched against everything but the final
component of the file name and the preceding slash. "*" will match
"foo/bar", but not "foo" or "foo/bar/baz", using these flags. This
causes tar a good deal of confusion.

There are two other places in names.c where FNM_LEADING_DIR is used;
however, they don't use FNM_FILE_NAME, and here the behaviour of
fnmatch() is different, even in the absence of wildcards. The pattern
"foo" matches "foo", "foo/bar", and "foo/bar/baz", as does the pattern
"*".

Have a look at the output of the following program (0 indicates a
successful match, 1 indicates a failure):

===== cut here =====
#include <fnmatch.h>
#include <stdio.h>

int main()
{
    printf("%d %d %d\n",
	    fnmatch("x", "x", FNM_FILE_NAME | FNM_LEADING_DIR),
	    fnmatch("x", "x/y", FNM_FILE_NAME | FNM_LEADING_DIR),
	    fnmatch("x", "x/y/z", FNM_FILE_NAME | FNM_LEADING_DIR));
    printf("%d %d %d\n",
	    fnmatch("*", "x", FNM_FILE_NAME | FNM_LEADING_DIR),
	    fnmatch("*", "x/y", FNM_FILE_NAME | FNM_LEADING_DIR),
	    fnmatch("*", "x/y/z", FNM_FILE_NAME | FNM_LEADING_DIR));
    printf("%d %d %d\n",
	    fnmatch("*x", "x", FNM_FILE_NAME | FNM_LEADING_DIR),
	    fnmatch("*x", "x/y", FNM_FILE_NAME | FNM_LEADING_DIR),
	    fnmatch("*x", "x/y/z", FNM_FILE_NAME | FNM_LEADING_DIR));
    printf("%d %d %d\n",
	    fnmatch("x*", "x", FNM_FILE_NAME | FNM_LEADING_DIR),
	    fnmatch("x*", "x/y", FNM_FILE_NAME | FNM_LEADING_DIR),
	    fnmatch("x*", "x/y/z", FNM_FILE_NAME | FNM_LEADING_DIR));
}
===== cut here =====

(Incidentally, if you put the two #includes the other way round, you
get:

[cjw44@riva ~/src/fnmatch-bug]$ gcc -c -g test.c
test.c: In function `main':
test.c:7: `FNM_LEADING_DIR' undeclared (first use in this function)
test.c:7: (Each undeclared identifier is reported only once
test.c:7: for each function it appears in.)
test.c:23: `FNM_FILE_NAME' undeclared (first use in this function)

This has got to be a bug too.)

This program outputs:

0 0 0
1 0 1
0 0 0
1 0 1

Thus, final *s will only allow one trailing slash and file name
component in the presence of FNM_FILE_NAME and FNM_LEADING_DIR, whereas
other atoms in patterns don't care how many there are. If you remove the
FNM_FILE_NAME flag so that *s can match slashes, then all these matches
succeed, as you might expect.

If this (strange, I think) behaviour really is by design and/or POSIX,
then it needs to be documented. If not, the following patch fixes it:

--- glibc-2.1.3.orig/posix/fnmatch.c	Thu Jun 22 23:17:14 2000
+++ glibc-2.1.3/posix/fnmatch.c	Thu Jun 22 23:24:41 2000
@@ -204,25 +204,18 @@
 	  if (c == '\0')
 	    /* The wildcard(s) is/are the last element of the pattern.
 	       If the name is a file name and contains another slash
-	       this does mean it cannot match.  If the FNM_LEADING_DIR
-	       flag is set and exactly one slash is following, we have
-	       a match.  */
+	       this means it cannot match, unless the FNM_LEADING_DIR
+	       flag is set.  */
 	    {
 	      int result = (flags & FNM_FILE_NAME) == 0 ? 0 : FNM_NOMATCH;

 	      if (flags & FNM_FILE_NAME)
 		{
-		  const char *slashp = strchr (n, '/');
-
 		  if (flags & FNM_LEADING_DIR)
-		    {
-		      if (slashp != NULL
-			  && strchr (slashp + 1, '/') == NULL)
-			result = 0;
-		    }
+		    result = 0;
 		  else
 		    {
-		      if (slashp == NULL)
+		      if (strchr (n, '/') == NULL)
 			result = 0;
 		    }
 		}

Thanks,

-- 
Colin Watson                                     [cjw44@flatline.org.uk]

Bug reassigned from package `tar' to `libc6'. Request was from Colin Watson <cjw44@flatline.org.uk> to control@bugs.debian.org. (full text, mbox, link).

Message sent on to Ryan Tracey <ryant@thawte.com>:
Bug#59829. (full text, mbox, link).

Changed Bug title. Request was from Colin Watson <cjw44@flatline.org.uk> to control@bugs.debian.org. (full text, mbox, link).