This patch isn't valid. Other applications will play games with comparisons. Comparisons require users to call TRUEPATH. What seems to be needed here is for apr_pathname_cwd to be returning a true path.
All other comparisons are intrinsically invalid, and this has the potential to introduce security issues in other applications which rely on comparing path names. On 7/5/2010 2:38 PM, Greg Stein wrote: > Applied in r960665 to trunk. > > Backports will be needed before future branch releases (unsure what > the schedule is for that). > > Thanks, > -g > > On Mon, Jul 5, 2010 at 08:43, Bert Huijben <b...@qqmail.nl> wrote: >> Hi, >> >> As mailed in November 2009 [1], simple apr_filepath_merge() calls on paths >> like "C:/Windows" fail for users that use a shell that turns their active >> directory in a "c:/users/bert" style instead of the more common >> "C:/users/bert" (note the lower case 'C'). >> >> The current APR code just assumes that drive letters returned by the Windows >> current path functions are always uppercase, which is not the case. This >> issue is reported every few months on different Subversion mailinglists and >> probably seen much more often by users that can't explain any of this. >> >> The patch attached to this mail removes the assumption that the drive >> letters must always be uppercase and adds a test which shows the error >> behavior. Easier ways to reproduce are adding a program shortcut with a >> lower case letter in the 'Start In' box, using CygWin or using 'CD /D >> c:\windows' in a dos prompt. >> (See also dirent_uri-tests.exe 36 in Subversion) >> >> >> I'm willing to work on more patches to improve APR and especially APR's >> performance on Windows, but if even this most important patch for me (and >> other Windows Subversion users) takes more than half a year to apply even >> with periodic pinging (some on private@), I can probably better spend my >> time starting my own APR patches for Windows project. >> >> >> For other long delayed Windows specific patches from me and others see [2] >> and [3] (but these didn't receive the same amount of review as [1]). >> >> Bert >> >> >> [1] http://marc.info/?t=125737717900001&r=1&w=3 >> [2] http://marc.info/?t=127143172200001&r=1&w=2 >> [3] http://marc.info/?l=apr-dev&m=127219937825412 >> >> >
