> -----Original Message-----
> From: William A. Rowe Jr. [mailto:wr...@rowe-clan.net]
> Sent: maandag 14 maart 2011 18:22
> To: Bert Huijben; APR Developer List
> Subject: Re: apr 1.4.3, apr-util 1.3.11
>
> On 3/14/2011 12:11 PM, Bert Huijben wrote:
> >>
> >> Sorry to have left it hanging.
> >
> > As long as it properly fixes the testcase added with this patch, I really
> > don't
> mind a better fix.
> >
> > Normally you get in this state before starting the application that uses
> > Apr;
> not from inside the application (see the original thread from November
> 2009). So getting in the error state is not an application error!
> > But reproducing it that way would require a more extensive test.
>
> Well, what I want to clarify is that, with this patch, does *your* application
> actually work comparing C:/Program Files from c:/progra~1/ from
> C:\PROGRAM FILES
> etc? If not, this was a mis-application of apr's comparison API. If it does,
> then this fix (or something related, perhaps fixing apr_filepath_get()) might
> be more appropriate.
These examples don't apply to this change.
It just makes "C:\PROGRAM FILES" equivalent to "c:\PROGRAM FILES" in this
specific check deep inside apr_filepath_merge(). Any other change would make it
unequal.
It fixes that single letter compare of the drive letter which caused the merge
filepath api to choke on the example I added as a testcase.
When your current directory happens to be "c:\hello" instead of "C:\hello" then
you can't use apr_filepath_merge() without this patch.
Any application that uses apr_filepath_merge() to get an absolute path from a
relative path is broken.... but only if the current directory before starting
the application is based on a lower case drive letter.
This is not a common condition, but this patch just fixes that specific error
condition.
It doesn't alter the comparison of paths.... It fixes an API bug.
Bert
