make file/dirnm comparison in relativeFilename case-insensitive for WIN32 #1893
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Issue
Running recent https://github.com/universal-ctags/ctags-win32/releases builds including ctags-2018-09-25_619a6fac-x64
This behavior occurs with
--tag-relative=yes
and--tag-relative=always
.Diagnosis
(using MinGW builds of current master branch) showed that
getcwd
function called bysetCurrentDirectory
is returning a lowercase drive-letter on Win10, and a uppercase drive-letter on Win8.1 (I can think of no explanation for this behavior, as I assume this routine is statically linked into ctags.exe; while diagnosing this issue I copied locally-built MinGW ctags.exe binaries from Win10 to Win8.1 host and observed same results as when using the ctags-win32/releases builds per above).The existing ctags function
relativeFilename
(case-sensitively) compares this (setCurrentDirectory
) value against the output ofabsoluteFilename( tagfile-name )
in order to determine the relative path; this comparison fails if there is a mismatch on the 0th character (in WIN32: the drive-letter);absoluteFilename
contains WIN32-specific code that forces the drive-letter of its return value to uppercase, causing its output to match the (uppercase) drive-letter of Win8.1setCurrentDirectory
value (allowing a common path-prefix to be detected, and a valid relative path constructed), but to always mismatch the (lowercase) drive-letter of Win10setCurrentDirectory
value (preventing construction of a relative path, the issue).Offered Fix
Because I wish to avoid falling into the tarpit of adding more/competing code to ensure (or assume) a specific case for the WIN32 drive-letter character (when the underlying filesystem is case-insensitive!?), the fix in this PR takes the approach of changing the filename comparison operation performed in
relativeFilename
to be case-insensitive on WIN32, a behavior which I believe to be in alignment with the characteristics of filesystem on that platform.