Bruno Haible writes:
Hello!
> Jan Nieuwenhuizen wrote:
>> Do you see a cheap way to return the correct casing for the rest of the
>> file name?
>
> No. [1]
Check, thanks.
>> I agree it's quite debatable and a bit arbitrary to correct drive name
>> casing. The reasons why opted to put in after all are:
>>
>> * it's cheap (I had the impression that if we found a cheap way to
>> return the canonical casing for the full file name, as opposed to
>> the unacceptably expensive scandir "solution", it might be
>> something that could be discussed),
>
> Still, it's adding complexity. And it does not help solving the original
> problem, namely that the processor that interprets
> #include "c:/foo.h"
> #include "C:/FOO.H"
> #include "C:\\FOO.H"
> cannot just assume that different file names correspond to different
> files on disk.
Yes, but this example shows the mixing of three problems: wrong drive
letter casing, difference in type of slash, difference in casing of the
file name.
> Why add complexity if solving the root problem requires a different
> approach anyway?
Because we thought harder about the root problem, and found reasons to
re-define it, slightly. It was argued that it can be a *feature* that
canonicalize_file_name does not change the casing of the file-name part.
When the client software is run under other conditions, e.g., under
GNU/Linux or when a user uses a registry setting that changes the
Windows file system to be case-sensitive (apparently this is a
possibility), the behaviour would change. So, it is acceptable to have
the user be responsible for using the correct file-name casing, and if
the user inputs the wrong casing, they might get unexpected results,
which is OK.
However, with the current implementation, even if the user supplies
the file name with the correct casing, canonicalize_file_name still
returns different results.
Currently, using CWD=~/.wine/drive_c/windows, calling
canonicalize_file_name on variations of "system.ini" gives three
trivially different results, one of which mixes '/' and '\\':
input to canonicalize_file_name output
system.ini: => "C:\\windows/system.ini"
..\windows\system.ini: => "C:\\windows/system.ini"
../windows/system.ini: => "C:\\windows/system.ini"
C:/windows/system.ini: => "C:/windows/system.ini"
which means that currently, even if the casing of the file name is
correct, canonicalize_file_name cannot be used to determine equality,
but only on Windows. That's real unfortunate, hence this patch! :-)
If canonicalize_file_name would alway produce the last result, which is
what this patch does, our MinGW problem is suffinciently fixed without
having to modify our client code!
The patch as I presented it also canonicalizes the drive letter, as this
does not have the portibility concerns, so that an otherwise correct
file name with a wrong (non-canonical), lower drive letter, which now
produces yet another variant:
input to canonicalize_file_name output
c:/windows/system.ini: => "c:/windows/system.ini"
would gives the same result. This canonicalization of the drive letter
is not important for me, just nice to have, so please feel free to
remove that!
Greetings,
Janneke
--
Jan Nieuwenhuizen <jann...@gnu.org> | GNU LilyPond http://lilypond.org
Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.com
