Re: [Boost-build] <install-source-root> in Windows doesn't work with case-insensitive matching

Subject: Re: [Boost-build] <install-source-root> in Windows doesn't work with case-insensitive matching
From: Jose . (kasty.jose_at_[hidden])
Date: 2014-03-22 17:16:31

I finally isolated the bug in builtin GLOB. Consider the following example:

# Jamroot file at C:\Jam.
# A dummy text file at C:\AaA\BbB\File.txt

using msvc ;
import path ;

path-constant TOP : . ;
ECHO [ GLOB $(TOP)/../AaA/BbB : * ] ;

We execute:

C:\Jam>  bjam

The output should be:

C:\Jam\..\AaA\BbB\File.txt

but in fact is:

C:\Jam\..\aaa\bbb\File.txt

I think there might be a bug either in:

a) canonicWindowsPath() (pathnt.c). It takes as input a normalized string
like c:\\jam\\..\\aaa\\bbb\\file.txt. Notice that folder separator are
normalized windows-style (\\), and all characters are lower-case. At some
point, it uses FindFirstFileA() and replaces the first part of the path,
until "..", with the correct one as read from the filesystem, leaving the
rest unchanged: "c:\\Jam\\..\\aaa\\bbb\\File.txt. Funny: the file name is
ok, it just leaves the normalization in the subdirs between the ".." and
the file name.

b) path_key() (pathnt.c). It normalizes the input string. Surely because
that's a pre-requisite for canonicWindowsPath(). The point is: why does
canonicWindowsPath() have such a pre-requisite?

I guess any solution will need to fix canonicWindowsPath() anyway, which
states itself as "FIXME: work-in-progress". I tried to replace most of its
code with a call to Win32 API GetFullPathName() but it didn't work. May
someone more experienced have a look?

Regards.