https://bugs.exim.org/show_bug.cgi?id=2794
Bug ID: 2794
Summary: pcre2grep directory recursion has trouble with certain
symlinks on macOS
Product: PCRE
Version: 10.37 (PCRE2)
Hardware: All
OS: All
Status: NEW
Severity: bug
Priority: medium
Component: Code
Assignee: Philip.Hazel@???
Reporter: tempelmann@???
CC: pcre-dev@???
When doing a recursive search with pcre2grep on my macOS system's home folder,
I eventually get tons of these error messages:
pcre2grep: Failed to open /Users/user/Applications/Wineskin/Kings Quest
6.app/Contents/Resources/dosdevices/z:/Applications/iTunes &
iPod/Senuti.app/Contents/Frameworks/CrashReporter.framework/Resources/Crash
Reporter.app/Contents/Frameworks/CrashReporter.framework/Resources/Crash
Reporter.app/Contents/Frameworks/CrashReporter.framework/Versions/A/Resources/Crash
Reporter.app/Contents/Frameworks/CrashReporter.framework/Versions/A/Resources/Crash
Reporter.app/Contents/Frameworks/CrashReporter.framework/Versions/A/Resources/Crash
Reporter.app/Contents/Frameworks/CrashReporter.framework/Versions/Current/Resources/Crash
Reporter.app/Contents/Frameworks/CrashReporter.framework/Versions/A/Resources/Crash
Reporter.app/Contents/Frameworks/CrashReporter.framework/Versions/A/Resources/Crash
Reporter.app/Contents/Frameworks/CrashReporter.framework/Resources/Crash
Reporter.app/Contents/Frameworks/CrashReporter.framework/Versions/Current/Resources/Crash
Reporter.app/Contents/Frameworks/Sparkle.framework/Resources/fr.lproj/SUUpdateAlert.nib/classes.nib:
File name too long
The first oddity is the ":" in the path, which is a legal char on macOS (Finder
shows ":" as "/").
The item "z:" inside `/Users/user/Applications/Wineskin/Kings Quest
6.app/Contents/Resources/dosdevices` is a symlink pointing to "/":
$ ls -l /Users/user/Applications/Wineskin/Kings\ Quest\
6.app/Contents/Resources/dosdevices
total 16
lrwxrwxrwx 1 tempi wheel 10 Jul 23 2014 c:@ -> ../drive_c
lrwxrwxrwx 1 tempi wheel 1 Jul 23 2014 z:@ -> /
So, this seems fine, despite the unusual char in the path.
Then, since that symlink points to an ABSOLUTE and not a relative path, we
continue here:
$ ls -l "/Applications/iTunes &
iPod/Senuti.app/Contents/Frameworks/CrashReporter.framework/Resources"
lrwxr-xr-x 1 root wheel 26 Feb 6 2010 /Applications/iTunes &
iPod/Senuti.app/Contents/Frameworks/CrashReporter.framework/Resources ->
Versions/Current/Resources
This leads to the path
/Applications/iTunes &
iPod/Senuti.app/Contents/Frameworks/CrashReporter.framework/Versions/Current/Resources
Now, at this point, the path goes into
`Contents/Frameworks/CrashReporter.framework` - but there is not
`Contents/Frameworks`!
So, the symlink resolving goes awry somehow. I see two things going wrong:
1. If a symlinks points to an absolute path, it should not get concatenated to
but replace the current path.
2. If a symlink points to a nonexisting file, the recursion needs to be aborted
but it appears to continue going deeper, endless, until the path becomes too
long.
--
You are receiving this mail because:
You are on the CC list for the bug.
