Re: apr_realpath
On Wed, 14 Mar 2001 09:38:21 -0600, William A. Rowe, Jr. wrote: [...] 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/ Actually OS/2 does NOT have the long/short name crap that windows does. -- __ | Brian Havard | He is not the messiah! | | [EMAIL PROTECTED] | He's a very naughty boy! - Life of Brian | --
Re: apr_realpath
On Wed, Mar 14, 2001 at 03:29:49PM -0600, William A. Rowe, Jr. wrote:
From: Kevin Pilch-Bisson [EMAIL PROTECTED]
Sent: Wednesday, March 14, 2001 3:08 PM
Would there be a way to convert an incomplete path to a complete path?
(change drive to c:, getpwd, append foo, in the above example)
That is what apr_filepath_merge does for you. You can pass a partial
root [/ or d:]
apr_filepath_root over to apr_filepath_merge as the addpath (with a null
root). That
will return a true root. apr_filepath_root is as much to help
apr_filepath_merge
(and any other app) break apart the root from a name, since the root is
very platform
specific (moreso than any other part of this debate.) Look at netware
machine/sys:/
versus win32/os2, toss in unc names and unix remote volumes and ugh, what
a mess.
I believe you, I am just a little confused as to the process. Say I do
the following:
C:\mywork\subversion\ svn commit C:foo
which eventually reaches the following code.
char added_path[][] = { C:foo, NULL };
(or should this be { C:, foo, NULL }; ?)
char *newpath;
apr_filepath_merge(newpath, NULL, added_path, APR_FILEPATH_TRUEPATH, p);
What do I get back from apr_filepath_merge? Or more to the point, how
can I get C:\mywork\subversion\foo as newpath?
Simply, rootpath == NULL uses CWD, therefore c:\mywork\subversion.
char *newpath = foo
char **addpath = newpath
char **newpath;
apr_filepath_merge(newpath, NULL, addpath, APR_FILEPATH_TRUEPATH, p);
If foo exists, newpath == c:\mywork\subversion\foo, and addpath += 4
(points to the trailing NULL of the string you passed).
If foo is not found, newpath == c:\mywork\subversion\ and addpath didn't
change (the path wasn't found.
If you pass foo/bar as addpath, and foo exists, then .../foo/ is retured
for newpath, and addpath += 4 (pointing at bar) if bar was not found.
Of course, without APR_FILEPATH_TRUEPATH, the whole thing just returns, and
doesn't care if the path names are real. With APR_FILEPATH_TRUECASE, those
parts that exist are returned with the correct case followed by the remaining
given path, since it also doesn't care if the files exist, only that the
names that exist are the proper case. Both of these would set point addpath
to it's own trailing NULL.
The Q. remains, do we want char** addpath, or simply a char* with no feedback
of existing v.s. nonexisting path components?
Bill
Right. Now say the target was D:foo, but my current drive was C:, as in
D:\mywork\subversion C:
C:\Program Files\Subversion svn commit D:foo
How do I find out that D:foo is really D:\mywork\subversion\foo?
On another note, I thought of another root case to be handled under
UNIX. Cygwin with windows drives. I.e. / is %SYSDRIVE%:\, but //c/ is
C:\ and //d/ is D:\. The double slashes are important to cygwin.
What a PITA. Sometimes I don't know whether I am glad for cygwin
because it makes having to use 'Doze at work less annoying, or pissed of
because of the hassle it makes for real unix development!
--
~
Kevin Pilch-Bissonhttp://www.pilch-bisson.net
Historically speaking, the presences of wheels in Unix
has never precluded their reinvention. - Larry Wall
~
Re: apr_realpath
From: Brian Havard [EMAIL PROTECTED] Sent: Wednesday, March 14, 2001 7:39 PM On Wed, 14 Mar 2001 09:38:21 -0600, William A. Rowe, Jr. wrote: [...] 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/ Actually OS/2 does NOT have the long/short name crap that windows does. Good point. Quick question ... it does have case insensitivty and drive/path (with current paths of each drive, correct?) And it does or doesn't have unc notation (sorry, I know you have answered that before, I get lost :-?) Bill
Re: apr_realpath
On Wed, 14 Mar 2001 21:08:01 -0600, William A. Rowe, Jr. wrote: From: Brian Havard [EMAIL PROTECTED] Sent: Wednesday, March 14, 2001 7:39 PM Actually OS/2 does NOT have the long/short name crap that windows does. Good point. Quick question ... it does have case insensitivty and drive/path (with current paths of each drive, correct?) And it does or doesn't have unc notation (sorry, I know you have answered that before, I get lost :-?) Yes, all that's the same as Win32 along with trailing . and space truncation. -- __ | Brian Havard | He is not the messiah! | | [EMAIL PROTECTED] | He's a very naughty boy! - Life of Brian | --
Re: apr_realpath
Here are some things I got from this. On Tue, Mar 13, 2001 at 01:40:02AM -0600, William A. Rowe, Jr. wrote: Here is what I've worked up thus far for Unix... n'er mind the _more_ complicated Win32 beast [all I could do to get the _root_ parsing finished tonight!] So feel free to look at the server root parse function, and the unix implementation of apr_filepath_merge(), and let me know if I've gone off in the wrong direction. Survey; is there any reason -not- to canonicalize a name, ever (/./ elimination, etc)? Not that I can think of. Is there a decent semantic to append a missing trailing slash for a directory vs. a file? Not sure exactly what you are asking. Should we have a char** input argument for addpath (who cares about realpath) so that we can actually return the user the existing path, while incrementing the pointer to the start of the non-existinant path (a slow operation, by request only)? Why? Should we persist in forcing Win32 to use slashes, or should we return backslashes? Subversion uses native path separators. I don't know what the rest of APR/Apache do. Last comment (not a q)... I will round out the Win32 code and add apr_pathname_segment() fn to pull apart a path, which is what I got out of kevin's request, and what I need for the Apache core. Actually, I am looking for a function to portably, always get an absolut path from a given string. I'll try to give you a use case for it. In subversion, we have the idea of commits, where you can give a list of targets on the command line. [EMAIL PROTECTED]:/home/kevin/repos$ svn commit file1 dir/file2 /home/kevin/repos/dir2/file3 From that command, we would like to be able to take the three file arguments, and find out what is the deepest directory which is common to all three targets, since that is where we have to start making changes to our repository. In the above example that would be /home/kevin/repos. We already have a function which takes a list of (absolute) targets, finds the common part of the path, and converts the other targets to relative paths from that base. Now we need a portable way to convert the targets given above into absolute paths. The problem we ran into is that while realpath exists on unix, and _fullpath exists on win32, there is nothing (that we knew about anyway, on BeOS). Also, realpath is known to be broken on some older versions of Solaris, in that it merely canonicalizes a path if it is below the cwd. For now, we are just using realpath and _fullpath (and not putting our heads in the sand with respect to Solaris and BeOS. Bill Index: file_io/unix/filepath.c === RCS file: filepath.c diff -N filepath.c --- /dev/null Mon Mar 12 23:32:12 2001 +++ filepath.c Mon Mar 12 23:32:23 2001 @@ -0,0 +1,233 @@ +/* + * The Apache Software License, Version 1.1 + * + * Copyright (c) 2000-2001 The Apache Software Foundation. All rights + * reserved. + * + * Redistribution and use in source and binary forms, with or without + * modification, are permitted provided that the following conditions + * are met: + * + * 1. Redistributions of source code must retain the above copyright + *notice, this list of conditions and the following disclaimer. + * + * 2. Redistributions in binary form must reproduce the above copyright + *notice, this list of conditions and the following disclaimer in + *the documentation and/or other materials provided with the + *distribution. + * + * 3. The end-user documentation included with the redistribution, + *if any, must include the following acknowledgment: + * This product includes software developed by the + *Apache Software Foundation (http://www.apache.org/). + *Alternately, this acknowledgment may appear in the software itself, + *if and wherever such third-party acknowledgments normally appear. + * + * 4. The names Apache and Apache Software Foundation must + *not be used to endorse or promote products derived from this + *software without prior written permission. For written + *permission, please contact [EMAIL PROTECTED] + * + * 5. Products derived from this software may not be called Apache, + *nor may Apache appear in their name, without prior written + *permission of the Apache Software Foundation. + * + * THIS SOFTWARE IS PROVIDED ``AS IS'' AND ANY EXPRESSED OR IMPLIED + * WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES + * OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE + * DISCLAIMED. IN NO EVENT SHALL THE APACHE SOFTWARE FOUNDATION OR + * ITS CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, + * SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT + * LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF + * USE, DATA,
Re: apr_realpath
On Wed, Mar 14, 2001 at 09:38:21AM -0600, William A. Rowe, Jr. wrote:
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.
Sorry, I think it has to do with the way mutt handles pgp signing
messages. I'm not going to sign this one, so hopefully it won't do so.
Offhand, which pathetic win32 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.
[snip explanation]
OOhhh, now I understand. I like!
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.
No, no, no. I don't like that at all.
I didn't miss your question on comparing paths, we need to add these other
functions:
Actually, for now I think I can do what I need with just
apr_filepath_merge, with NULL, rootpath arguments. (We have existing
svn functions to do the rest, although in time they would probably be
re-worked to use the below).
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).
Would there be a way to convert an incomplete path to a complete path?
(change drive to c:, getpwd, append foo, in the above example)
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.
Will keep thinking about this.
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/
Canonicalizing is done by apr_filepath_merge, with NULL rootpath, right?
Bill
--
~
Kevin Pilch-Bissonhttp://www.pilch-bisson.net
Historically speaking, the presences of wheels in Unix
has never precluded their reinvention. - Larry Wall
~
Re: apr_realpath
Kevin Pilch-Bisson [EMAIL PROTECTED] writes: Sorry, I think it has to do with the way mutt handles pgp signing messages. I'm not going to sign this one, so hopefully it won't do so. Offhand, which pathetic win32 client. X-Mailer: Microsoft Outlook Express 5.50.4133.2400 Just a guess. :-)
Re: apr_realpath
On Wed, Mar 14, 2001 at 12:34:39PM -0600, [EMAIL PROTECTED] wrote: Kevin Pilch-Bisson [EMAIL PROTECTED] writes: Sorry, I think it has to do with the way mutt handles pgp signing messages. I'm not going to sign this one, so hopefully it won't do so. Offhand, which pathetic win32 client. X-Mailer: Microsoft Outlook Express 5.50.4133.2400 Just a guess. :-) Doh! I have ignores set up for most standard mail headers. Don't I feel silly. -- ~ Kevin Pilch-Bissonhttp://www.pilch-bisson.net Historically speaking, the presences of wheels in Unix has never precluded their reinvention. - Larry Wall ~
Re: apr_realpath
From: Kevin Pilch-Bisson [EMAIL PROTECTED]
Sent: Wednesday, March 14, 2001 11:39 AM
Sorry, I think it has to do with the way mutt handles pgp signing
messages. I'm not going to sign this one, so hopefully it won't do so.
Offhand, which pathetic win32 client.
Message is fine, I'm using MeSsed Outlook Express (which actually, usually
handles
pgp signed messages, as opposed to the MS Office Outlook).
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).
Would there be a way to convert an incomplete path to a complete path?
(change drive to c:, getpwd, append foo, in the above example)
That is what apr_filepath_merge does for you. You can pass a partial root [/
or d:]
apr_filepath_root over to apr_filepath_merge as the addpath (with a null root).
That
will return a true root. apr_filepath_root is as much to help
apr_filepath_merge
(and any other app) break apart the root from a name, since the root is very
platform
specific (moreso than any other part of this debate.) Look at netware
machine/sys:/
versus win32/os2, toss in unc names and unix remote volumes and ugh, what a
mess.
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/
Canonicalizing is done by apr_filepath_merge, with NULL rootpath, right?
Yes, or by merging the untrusted path onto a known canonical path (say a
ServerRoot or
DocumentRoot already canonicalized within Apache's server structure.)
Re: apr_realpath
From: Kevin Pilch-Bisson [EMAIL PROTECTED]
Sent: Wednesday, March 14, 2001 3:08 PM
Would there be a way to convert an incomplete path to a complete path?
(change drive to c:, getpwd, append foo, in the above example)
That is what apr_filepath_merge does for you. You can pass a partial root
[/ or d:]
apr_filepath_root over to apr_filepath_merge as the addpath (with a null
root). That
will return a true root. apr_filepath_root is as much to help
apr_filepath_merge
(and any other app) break apart the root from a name, since the root is
very platform
specific (moreso than any other part of this debate.) Look at netware
machine/sys:/
versus win32/os2, toss in unc names and unix remote volumes and ugh, what a
mess.
I believe you, I am just a little confused as to the process. Say I do
the following:
C:\mywork\subversion\ svn commit C:foo
which eventually reaches the following code.
char added_path[][] = { C:foo, NULL };
(or should this be { C:, foo, NULL }; ?)
char *newpath;
apr_filepath_merge(newpath, NULL, added_path, APR_FILEPATH_TRUEPATH, p);
What do I get back from apr_filepath_merge? Or more to the point, how
can I get C:\mywork\subversion\foo as newpath?
Simply, rootpath == NULL uses CWD, therefore c:\mywork\subversion.
char *newpath = foo
char **addpath = newpath
char **newpath;
apr_filepath_merge(newpath, NULL, addpath, APR_FILEPATH_TRUEPATH, p);
If foo exists, newpath == c:\mywork\subversion\foo, and addpath += 4
(points to the trailing NULL of the string you passed).
If foo is not found, newpath == c:\mywork\subversion\ and addpath didn't
change (the path wasn't found.
If you pass foo/bar as addpath, and foo exists, then .../foo/ is retured
for newpath, and addpath += 4 (pointing at bar) if bar was not found.
Of course, without APR_FILEPATH_TRUEPATH, the whole thing just returns, and
doesn't care if the path names are real. With APR_FILEPATH_TRUECASE, those
parts that exist are returned with the correct case followed by the remaining
given path, since it also doesn't care if the files exist, only that the
names that exist are the proper case. Both of these would set point addpath
to it's own trailing NULL.
The Q. remains, do we want char** addpath, or simply a char* with no feedback
of existing v.s. nonexisting path components?
Bill
Re: apr_realpath
Here is what I've worked up thus far for Unix... n'er mind the _more_
complicated
Win32 beast [all I could do to get the _root_ parsing finished tonight!]
So feel free to look at the server root parse function, and the unix
implementation
of apr_filepath_merge(), and let me know if I've gone off in the wrong
direction.
Survey; is there any reason -not- to canonicalize a name, ever (/./
elimination, etc)?
Is there a decent semantic to append a missing trailing slash for a directory
vs. a file?
Should we have a char** input argument for addpath (who cares about realpath)
so that
we can actually return the user the existing path, while incrementing the
pointer to the
start of the non-existinant path (a slow operation, by request only)?
Should we persist in forcing Win32 to use slashes, or should we return
backslashes?
Last comment (not a q)... I will round out the Win32 code and add
apr_pathname_segment()
fn to pull apart a path, which is what I got out of kevin's request, and what I
need
for the Apache core.
Bill
Index: file_io/unix/filepath.c
===
RCS file: filepath.c
diff -N filepath.c
--- /dev/null Mon Mar 12 23:32:12 2001
+++ filepath.c Mon Mar 12 23:32:23 2001
@@ -0,0 +1,233 @@
+/*
+ * The Apache Software License, Version 1.1
+ *
+ * Copyright (c) 2000-2001 The Apache Software Foundation. All rights
+ * reserved.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions
+ * are met:
+ *
+ * 1. Redistributions of source code must retain the above copyright
+ *notice, this list of conditions and the following disclaimer.
+ *
+ * 2. Redistributions in binary form must reproduce the above copyright
+ *notice, this list of conditions and the following disclaimer in
+ *the documentation and/or other materials provided with the
+ *distribution.
+ *
+ * 3. The end-user documentation included with the redistribution,
+ *if any, must include the following acknowledgment:
+ * This product includes software developed by the
+ *Apache Software Foundation (http://www.apache.org/).
+ *Alternately, this acknowledgment may appear in the software itself,
+ *if and wherever such third-party acknowledgments normally appear.
+ *
+ * 4. The names Apache and Apache Software Foundation must
+ *not be used to endorse or promote products derived from this
+ *software without prior written permission. For written
+ *permission, please contact [EMAIL PROTECTED]
+ *
+ * 5. Products derived from this software may not be called Apache,
+ *nor may Apache appear in their name, without prior written
+ *permission of the Apache Software Foundation.
+ *
+ * THIS SOFTWARE IS PROVIDED ``AS IS'' AND ANY EXPRESSED OR IMPLIED
+ * WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES
+ * OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
+ * DISCLAIMED. IN NO EVENT SHALL THE APACHE SOFTWARE FOUNDATION OR
+ * ITS CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
+ * SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
+ * LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF
+ * USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND
+ * ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY,
+ * OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT
+ * OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
+ * SUCH DAMAGE.
+ *
+ *
+ * This software consists of voluntary contributions made by many
+ * individuals on behalf of the Apache Software Foundation. For more
+ * information on the Apache Software Foundation, please see
+ * http://www.apache.org/.
+ */
+
+#include apr.h
+#include fileio.h
+#include apr_file_io.h
+#include apr_strings.h
+#if APR_HAVE_UNISTD_H
+#include unistd.h
+#endif
+
+#include direct.h
+
+
+APR_DECLARE(apr_status_t) apr_filepath_root(const char **rootpath,
+const char **inpath, apr_pool_t *p)
+{
+if (**inpath == '/') {
+*rootpath = apr_pstrdup(p, /);
+++*inpath;
+return APR_EABSOLUTE;
+}
+
+*rootpath = apr_pstrdup(p, );
+return APR_ERELATIVE;
+}
+
+
+APR_DECLARE(apr_status_t)
+apr_filepath_merge(char **newpath, const char *rootpath,
+ const char *addpath, apr_int32_t flags,
+ apr_pool_t *p)
+{
+char path[APR_PATH_MAX];
+apr_size_t newseg, addseg, endseg, rootlen;
+
+if (!rootpath) {
+/* Start with the current working path
+ * XXX: Any kernel subject to goofy, uncanonical results
+ * must test the cwd against the user's given flags.
+ * Simplest
