Ugh. canonical pain for OS2

["William A. Rowe, Jr." <wr...@rowe-clan.net>]

There are reports that 1.3.14 no longer likes the syntax
LoadModule d:\test\this\mod.dll
the unfortunate result is c:/root/d:\test\this\mod.dll

Pretty obvious why.

I believe we need to introduce the following unix noop, win32 fix.
However it will break OS2:

 API_EXPORT(char *) ap_server_root_relative(pool *p, char *file)
 {
+    file = ap_canonical_filename(p, file);
     if(ap_os_is_path_absolute(file))
         return file;
     return ap_make_full_path(p, ap_server_root, file);
 }

Since canonical_name in Unix is a noop (relative remains relative)
and Win32 retains relative paths, I'm afraid we aught to consider
the draconian measure of applying this patch and expecting OS2 to
keep up.  I realize this isn't terribly fair to you, Brian :-(

So what are your thoughts, given this situation?  Do we go back
to accepting "\" in ap_os_is_path_absolute?  I'm certain that isn't
what we want.

Bill

RE: Ugh. canonical pain for OS2

["William A. Rowe, Jr." <wr...@rowe-clan.net>]

> From: Brian Havard [mailto:brianh@kheldar.apana.org.au]
> Sent: Thursday, October 19, 2000 5:20 AM
> 
> >Since canonical_name in Unix is a noop (relative remains relative)
> >and Win32 retains relative paths, I'm afraid we aught to consider
> >the draconian measure of applying this patch and expecting OS2 to
> >keep up.  I realize this isn't terribly fair to you, Brian :-(
> >
> >So what are your thoughts, given this situation?  Do we go back
> >to accepting "\" in ap_os_is_path_absolute?  I'm certain that isn't
> >what we want.
> 
> I'd argue that any relative path isn't canonical as its meaning varies with
> the cwd. The correct fix should be to make ap_os_is_path_absolute() work.
> ap_os_canonical_filename() != ap_convert_backslashes_to_forward_slashes().

  ap_os_canonical_filename != ap_make_fullpath, either.

I'd reckon you are philisophically right, which is why I strongly believe
this function always has been misnamed.  I'd agree it is also more complex 
than s|\|/|.  That doesn't change the fact that it is not absolute, and we
have a function that should do so.  Any other solution breaks compatibility
and trust between os2 and unix.

Re: Ugh. canonical pain for OS2

[Brian Havard <br...@kheldar.apana.org.au>]

On Wed, 18 Oct 2000 23:37:22 -0500, William A. Rowe, Jr. wrote:

>There are reports that 1.3.14 no longer likes the syntax
>LoadModule d:\test\this\mod.dll
>the unfortunate result is c:/root/d:\test\this\mod.dll
>
>Pretty obvious why.
>
>I believe we need to introduce the following unix noop, win32 fix.
>However it will break OS2:
>
> API_EXPORT(char *) ap_server_root_relative(pool *p, char *file)
> {
>+    file = ap_canonical_filename(p, file);
>     if(ap_os_is_path_absolute(file))
>         return file;
>     return ap_make_full_path(p, ap_server_root, file);
> }
>
>Since canonical_name in Unix is a noop (relative remains relative)
>and Win32 retains relative paths, I'm afraid we aught to consider
>the draconian measure of applying this patch and expecting OS2 to
>keep up.  I realize this isn't terribly fair to you, Brian :-(
>
>So what are your thoughts, given this situation?  Do we go back
>to accepting "\" in ap_os_is_path_absolute?  I'm certain that isn't
>what we want.

I'd argue that any relative path isn't canonical as its meaning varies with
the cwd. The correct fix should be to make ap_os_is_path_absolute() work.
ap_os_canonical_filename() != ap_convert_backslashes_to_forward_slashes().

-- 
 ______________________________________________________________________________
 |  Brian Havard                 |  "He is not the messiah!                   |
 |  brianh@kheldar.apana.org.au  |  He's a very naughty boy!" - Life of Brian |
 ------------------------------------------------------------------------------