Red Hat Bugzilla – Bug 126460
glob does not match dead symlinks
Last modified: 2017-03-06 17:33:39 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4.1)
Description of problem:
When running glob with a pattern that is a filename, with the filename
referring to a dead symlink, glob returns GLOB_NOMATCH.
See the attached testcase.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Compile testcase.c and run a.out.
Actual Results: glob returned 3
Expected Results: There should be no output.
Created attachment 101318 [details]
Why do you think so?
Current glibc behaviour certainly matches e.g. Solaris glob behaviour.
Because it is matched by "dead-link*" and "dead-lin?".
I wouldn't complain if the behaviour was consistent, to not match dead
symlinks at all, but as they are matched if the pattern is indeed a
pattern, I think it's a bug.
Created attachment 101335 [details]
Patch to make glob_in_dir use __lstat64 instead of __stat64
The patch is against the glibc CVS.
(side note: shouldn't the __stat64/__lstat64 be in an ifdef HAVE_STAT64
Actually, dead-link* and dead-lin? should not match. I've made
appropriate changes in the upstream glibc. The result will appear in
Which standard specifies such dead-symlinks glob() behaviour? I'm
currently looking into http://www.opengroup.org/onlinepubs/009695399/
functions/glob.html and see no information about such specific case.
I disagree that the dead link should not be returned. This may be the behavior
on Solaris 8 through 10, but it is not the behavior on BSD and it disagrees with
the POSIX2 spec (http://www.opengroup.org/onlinepubs/009695399/functions/glob.html).
Nowhere does the POSIX2 glob spec specify that a broken symlink should not be
considered an "existing pathname". After all, the link exists, only its target
does not. Interpreted in this way, glob cannot be used by a program which, for
instance, wished to verify that all links matching a pattern had valid targets
since the broken links would not be returned by glob.
If glob is only going to consider a link as if it is its target, then what about
the case where a matching link points to a file in the same directory that also
matches the pattern? Should glob only return one or the other?
Perhaps a GNU extension similar to GLOB_ONLYDIR is in order
(GLOB_VERIFY_SYMLINKS?), but I do not think glob should be making these value
judgements when the user did not request it. It certainly does not appear to be
implied by the POSIX spec as I read it.
I have a patch for this issue including some efficiency improvements, but will
hold onto it until we finish the discussion of its applicability.
This bug should be reopened until repaired.
Oh, forgot to paste this leader to my last comment:
The POSIX2 glob spec states that glob returns GLOB_NOMATCH only when, "the
pattern does not match any existing pathname, and GLOB_NOCHECK was not set in
Paul Eggert cites an even better example: `Historically, the "*" pattern in the
shell has always matched dangling links. Otherwise "rm *" wouldn't work as
Paul has said he is preparing my patches for submission to the glibc bugs
mailing list. If he does not do this within a few days, I will look into doing
If the current (IMHO broken) behavior is kept, the manpage should be changed
as well. It contains "according to the rules used by the shell", I know of no
shell that doesn't expand dangling symlinks.