Mailing-List: contact dev-help@apr.apache.org; run by ezmlm
Precedence: bulk
Received-SPF: neutral (athena.apache.org: local policy)
From: "Bert Huijben" <bert@qqmail.nl>
To: "'William A. Rowe Jr.'" <wrowe@rowe-clan.net>,
	"'APR Developer List'" <dev@apr.apache.org>
References: <AANLkTi=TbLHm-en-S9MjGQNjFM+c6=nBwVCJNQHPwC2w@mail.gmail.com>
 <4D7BE1EA.40005@rowe-clan.net> <004d01cbe248$1e978400$5bc68c00$@qqmail.nl>
 <4D7E3ECF.2030504@rowe-clan.net> <040901cbe26a$ec4f6cb0$c4ee4610$@qqmail.nl>
 <4D7E4EAB.5080109@rowe-clan.net>
In-Reply-To: <4D7E4EAB.5080109@rowe-clan.net>
Subject: RE: apr 1.4.3, apr-util 1.3.11
Date: Mon, 14 Mar 2011 18:32:39 +0100
Message-ID: <040b01cbe26d$d19756a0$74c603e0$@qqmail.nl>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
thread-index: 
 AQHde2g1BbCRXn2ph4SktriyiqKNnQLC15vWAbV1ErkBfqfvhwHIRUCoAvOt+zaTtEq9UA==
Content-Language: nl


> -----Original Message-----
> From: William A. Rowe Jr. [mailto:wrowe@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
>=20
> 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.
>=20
> 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.=20


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