wxPATH_NORM_CASE doesn't normalize case

[ma_boehm]

This is a simple patch to the problem described in
[ 1885241 ] wxPATH_NORM_CASE doesn't norm case.

It simply has been forgotten that the path returned from GetLongPath must be made lower case as well.

[neis]

I normally don't care much about such minor efficiency issues, but I really wonder if it's necessary to
make both the short and the long path lower case, i.e. I'd suggest the slightly more efficient version that I
attached, but I don't have a suitable test environment at hand, so maybe there's a drawback I'm
overlooking?

File Added: norm_case_efficient.patch

[neis]

slightly more efficient version

[ma_boehm]

OK, here is a new patch, which bases on your idea; and moreover i removed some further unnecessary lines of code: it is enough to make the path lower case once at the end of the Normalize function! Only thing i had to add there is that the directory entries in the m_dirs member variable also have to be made lower case.
File Added: norm_case_patch3.patch

[ma_boehm]

an even better patch

[vadz]

I wanted to apply this patch but I also wanted to reproduce this bug first, to be able to verify that the patch really fixes it and unfortunately I was unable to do so: the tests I added in r53636 pass without problems. I'm using trunk (but the code in 2.8 seems identical) and Windows 2003, maybe GetLongPathName() behaves differently under different systems? Which Windows version do you have, ma_boehm?

Anyhow, it would be great if someone who _can_ reproduce the bug could apply this patch. And I also think that we don't need MakeLower() calls just above if wxPATH_NORM_LONG is also specified.

[ma_boehm]

Test case which reproduces the bug

[ma_boehm]

Ok, i'm using Windows *Vista*, and there is only *one* directory i know of which fails to be made lower case, that is C:\Users and all subdirectories as well. Windows Vista seems to treat this directory specially in GetLongPath, somehow.

I don't know whether there are other OS's with this directory (as user directory, i mean, because i think this is which makes Windows Vista treat that directory specially), but perhaps the error can be reproduced on other OS's with that directory as (special?) directory as well.
I added a test case, there are makefiles for borland+microsoft+mingw, and it assumes, that wxWidgets is installed in C:\wx (the files are actually taken from a project of mine), and you can control build by unicode=0/1 and debug=0/1.
I hope someone will reproduce this problem as well!

[wxsite]

changed from old 'need_feedback' to new 'infoneeded_new'

[wxsite]

changed from old 'need_feedback' to new 'infoneeded_new'

[ma_boehm]

I don't know which operation system you use, but i ask you to to repeat your test (r53636) with the C:\Users (!!!) directory on Windows Vista (!!!), if possible; i'm sure that then you can reproduce the error as well. As i said before this is the *only* directory and OS i know where the error appears.

[vadz]

Ok, I could test it under Vista and the bug is indeed present there (even with C:\Program Files, not only C:\Users, although I added the test for the latter in r53732 just in case, too.

This probably should be backported into 2.8 too, unless we find something wrong with the new code.

Thanks for your patch!

[vadz]

I feel we need to wait for a bit more to give more people a chance to test the new code.

[vadz]

Did anybody test this patch with 2.8 by chance? If not, I'm afraid we'd have to postpone backporting it as I'm too afraid to break something here.

[VZ]

(In [58751]) do case normalization after long path one, this fixes the problem with incorrect paths case under Vista [backport of r53732 from trunk] (closes #9162)