apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "William A. Rowe, Jr." <wr...@rowe-clan.net>
Subject Re: apr_realpath
Date Wed, 14 Mar 2001 15:38:21 GMT
From: "Kevin Pilch-Bisson" <kevin@pilch-bisson.net>
Sent: Wednesday, March 14, 2001 7:48 AM

>> Attachment

Huge favor, if you would, look into why all your posts are going in as text file
attachments?  At least they appear so on my pathetic Win32 email client.

To answer your questions:

apr_filepath_merge(char **newpath, char *rootpath, char **addedpath, APR_FILEPATH_TRUEPATH,

would allow us to take rootpath of '/usr/local/bin' and addedpath of 'apache/secure/conf',
merge them into '/usr/local/bin/apache/' [an existing path] and leave addedpath pointing
to 'secure/conf' [the non-existant portion of addedpath.]  The user can do whatever they like
to make them work.

I'm insisting that rootpath has always been 'preaccepted' by whatever mechanism you are
using (processed with APR_FILEPATH_TRUEPATH flag set) and is never optimized, tested or
canonicalized.  Any Truepath/Truecase operation will be very expensive, and we never want
to repeat it once we have processed that path the first time.

Now the programmer can split the remaining addedpath by segments (a new apr function as well)
so they append 'secure' and call apr_dir_make.  Then append conf and (since there are no more
segments) call apr_dir_make or apr_file_open and do their damage.

An http server can take that remainder and chug it through whatever parsing they like.

My point is that we have the possibility of knowing the 'remainder' even if we are asking
the existant elements by passing that flag.  

My only other 'simple' solution, if that flag is passed, is to append a second string following
the null of the root string.  If they pass that flag, the user is guarenteed a second null

(even if the entire given path was existed, so the non-existant result is empty.)

Since that is alien to everything we have done in APR, I'm hesistant to try it.

I didn't miss your question on comparing paths, we need to add these other functions:

apr_status_t apr_filepath_root(char** pathroot, char** name, apr_pool_t *p)
    Which returns the canonical form of the pathroot and returns the first non-root
    part of name (e.g. '/foo' is '/' 'foo' on unix, 'c:\foo' is 'c:\' 'foo' and
    '//machine/share/foo' is '//machine/share/' 'foo' on win32)
    Handles incomplete roots ('c:foo' on win32 is 'c:', 'foo', but returns a status

apr_status_t apr_filepath_elements_count(int *n, char *path)
    counts the elements given in the file path.  
    [counts the root as one element]

apr_status_t apr_filepath_elements_get(char **segments, char *path, int first, int last, apr_pool_t
    returns the requested elements of the file path.
    All even numbered elements are delimiters, so 0 is the delimited root,
    1 is the first name, 2 is the delimiter, 3 is the second name.    
    While more complex, this presupposes some platform could have a multi-byte
    delimiter (unlikely, but consider a utf-8 path delimiter char that is more
    than a single byte, not true of '/' or '\', but it's easier to code for it
    now than change it later.)

The even/odd theory falls apart for relative paths like foo/bar unless we return an
empty string for foo, so this needs more thought.

apr_status_t apr_filepath_common(char** result, char* a, char* b, apr_pool_t *p)
    returns the segments that match, comparing from the beginning.
    The user must canonicalize the paths first with apr_filepath_merge.
    /foo/bar compared to /foo/barstool  returns  /foo/
    compare does not distinguish between '/' and '\' on win32/os2 - they compare equal.
    If a and b were char**, we could point at the first uncommon element, but a strlen
    of result provides the same answer, no?  [This isn't true of the above example that
    is changing the case, eliminating trailing '.'s and ' 's from win32 names, and 
    converting short aliases to true names).

Canonicalizing first to the truename is required before apr_filepath_common can be
trusted on Win32 or OS2, since c:/thislongname/ is also c:/THISLO~1/


View raw message