Here's what I envision...
#define APR_DM_TRUECASE 0x01
#define APR_DM_NOTABOVEROOT 0x02
#define APR_DM_NOTRELATIVE 0x04
#define APR_DM_NOTABSOLUTE 0x08
#define APR_DM_CANONICAL 0x10
apr_status_t apr_dir_merge(char *newpath, const char *rootpath, const char
*addpath,
apr_int32_t flags, apr_pool_t *p)
Where rootpath may be null, but only newpath elements are proper cased. Why?
Since getting the true case is a slow operation, and we can trust rootpath
either
doesn't matter (true name only instead of true path) or was already truecased,
we
are halfway to the finish line :-) Also, don't assume root path is absolute.
It
could simply be 'foo' and addpath could be 'bar', resulting in foo/bar. Or in
that
same example, addpath could be '../../bar', resulting in '../bar' (relative to
foo).
NOTABOVEROOT means addpath can't be '../bar' [technically, it could. Should we
allow
the case where root /foo/bar + '../bar' is not above root?] Note that
NOTABOVEROOT
precludes returning a relative name that is '../anything', since that is above
whatever
root path it would be concatinated to, later.
NOTABSOLUTE and NOTRELATIVE mean just what they suggest. Note that if the
product
is not absolute, the name is never truecased.
Dirmerge will resolve all '..', '.', '//' and other pathing issues into a
canonical
form, iff CANONICAL is flagged. If not, a slash will be added iff the rootpath
isn't
slash terminated, e.g. 'foo' 'bar' will become 'foo/bar', but 'test/' 'path'
won't
ever inherit an extra slash, ever if CANONICAL is not specified.
Note especially, the rootpath is presumed to have been processed through the
appropriate TRUECASE and CANONICAL filters, and _only_ the addpath is parsed
by those rules. We are essensially asking, take this root, fix up this addpath,
and give us the new (more) complete path.
Doing all of these operations as single-pass should be quite quick. Can we all
live with this API? Other ideas, suggestions or pointers to my ommissions?
Sorry I couldn't wrap this today (and would like to read the feedback to this
proposal.) It's as fast as I can picture, and should work for 98% of the needs.
Comments are welcome.
Bill
----- Original Message -----
From: "David Reid" <[EMAIL PROTECTED]>
To: "APR Development List" <dev@apr.apache.org>
Sent: Saturday, March 03, 2001 9:55 AM
Subject: apr_realpath
> Did we ever get a point of agreeing if we wanted to add apr_realpath? I
> seem to have deleted the emails concerning it but ISTR that there was a
> patch?
>
> david
>
>
