From: "Kevin Pilch-Bisson" <[EMAIL PROTECTED]>
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, p)
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 for
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
of APR_EINCOMPLETE).
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 *p)
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/
Bill
