From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4.1) Gecko/20031030 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): glibc-2.3.3-27, glibc-2.3.2-101.4 How reproducible: Always Steps to Reproduce: 1. Compile testcase.c and run a.out. Actual Results: glob returned 3 Expected Results: There should be no output. Additional info:
Created attachment 101318 [details] Test case.
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 section?)
Actually, dead-link* and dead-lin? should not match. I've made appropriate changes in the upstream glibc. The result will appear in rawhide soon.
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 flags."
Paul Eggert cites an even better example: `Historically, the "*" pattern in the shell has always matched dangling links. Otherwise "rm *" wouldn't work as desired.' 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 it myself.
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.