httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Brian Havard" <>
Subject RE: [patch] 1.3.15 ap_os_is_path_absolute
Date Fri, 03 Nov 2000 04:42:09 GMT
On Thu, 2 Nov 2000 08:20:56 -0600, William A. Rowe, Jr. wrote:

>> From: Brian Havard []
>> Sent: Thursday, November 02, 2000 3:58 AM
>> [...] To produce a canonical file name you must
>> map all possible ways of specifying a particular file to a single value.
>> Considering that the CWD can change, the resulting value MUST be an
>> absolute path, including the drive letter if on a platform 
>> that uses them.
>YES, but... we are entirely rewriting canonical names for Apache 2.0.
>It is -too much- for 1.3 and the associated audit involved.

So you admit the OS/2 ap_os_canonical_filename() is in fact correct?

>It's too computationally intensive unless we cache the elements that have
>already been reformatted.  That's how canonical is prototyped for 2.0.

Resolving relative paths is nothing compared to the expense of looking up
each component in the file system which is done in
ap_os_systemcase_filename() which is called by
ap_os_case_canonical_filename() which is called by

>> No, that's not how I'd rather do it, I'd prefer to find the 
>> correct fix.  Why doesn't ap_os_is_path_absolute() look for 
>> backslashes on Win32?
>That was my proposed solution #1 - and I didn't veto, find 4 +1's to 
>push over my own -1 [not vetoing] and I will commit exactly that.

Why are you against it? I'd rather convince you to change your vote as
nobody else seems to be taking an interest in the issue.

Here's how I see it in a nutshell. You are trying to solve a problem. The
problem is that windows users can't use backslashes in their config files.
This is on the stable tree so the fix should be as simple & clear as
possible with no side effects. This leaves 2 options that I can see:

1) Make ap_os_is_path_absolute() check for both types of slashes.
2) Use ap_fix_slashes() as I previously posted.

I don't buy your namespace pollution argument against (2). Whoever said we
can't/shouldn't add new functions?

>IMHO, move the DosGetFullPath over to ap_make_full_path() in
>an #ifdef OS2 escape, and everyone shares predictable results.

I can't MOVE the "DosGetFullPath" call as it does most of the work of
canonicalization, not just resolving relative paths. In fact the only thing
it doesn't handle is case.

>We _will_ bang out a single source for canonical under APR for 
>both Win32 and OS2 (with a few #ifdef escapes for long names 
>or whatnot), and a single theory for all platforms (even the
>purish Un*x ones can have case insensitive, case preserving
>mount points today.)

Ouch, yes, that could get very tricky. At least on OS/2 & Win32 you can ask
what file system a drive is (although that's still no guarantee, a "LAN" FS
could be a case sensitive Samba share). On unix you can change file system
part way through a path and I don't know of any standard way of finding out
what it is.

>Look for that code this weekend, but 
>please don't pull me out to reargue an issue I've spent over a 
>full month auditing, debating, coding, and debugging.  It's a
>more predictable by an order of magnitude today.  And that's
>plenty for the 1.3.x family.

That's hardly fair. Just because you've put in a lot of time & don't want
to put in any more, we just have to accept that you're right?

I'm not keen on a protracted debate either but you're making my code out to
be the bad guy when it is in fact the better implementation. At very least
you should be using #ifdef WIN32 rather than #ifndef OS2 as this change is
only required to fix a windows problem, right?

 |  Brian Havard                 |  "He is not the messiah!                   |
 |  |  He's a very naughty boy!" - Life of Brian |

View raw message