apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "William A. Rowe, Jr." <ad...@rowe-clan.net>
Subject Re: apr_realpath
Date Sun, 04 Mar 2001 06:09:54 GMT
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.


----- Original Message ----- 
From: "David Reid" <dreid@jetnet.co.uk>
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

View raw message