You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Martin Kraemer <Ma...@mch.sni.de> on 1998/07/14 17:04:26 UTC
[BUG] Win32 assert: sub_canonical_filename() called with szFile==""
A colleague of mine just tried a compilation of today's apache-1.3.1-dev
under WinNT. He reports no major compilation problems, but
runs into an assertion in os/win32/util_win32.c line 24 because
sub_canonical_filename() -after being called several times successfully-
is finally called with an argument of szFile == "" (empty string).
GetFullPathName() then barfs and returns n==0 which triggers the
assertion.
Neither he nor I do have the full NT debugging environment to check this,
so can you Win guys please have a look at this problem?
Other than that, 1.3.1-dev runs fine here, and I'd like to congratulate
Ralf once again on the terrific Unix DSO handling he's implemented here.
Martin
PS: When's 1.3.1 due?
--
| S I E M E N S | <Ma...@mch.sni.de> | Siemens Nixdorf
| ------------- | Voice: +49-89-636-46021 | Informationssysteme AG
| N I X D O R F | FAX: +49-89-636-44994 | 81730 Munich, Germany
~~~~~~~~~~~~~~~~My opinions only, of course; pgp key available on request
Re: [BUG] Win32 assert: sub_canonical_filename() called with
szFile==""
Posted by Ben Hyde <bh...@pobox.com>.
I entirely agree with Marc, see if it can get out as is.
The hypothetical end to sillyness isn't worth
the delay. - ben hyde
Re: [BUG] Win32 assert: sub_canonical_filename() called with szFile==""
Posted by Rodent of Unusual Size <Ke...@Golux.Com>.
Marc Slemko wrote:
>
> No.
>
> We have been far too long with it already, there are other win32 problems
> far more important than this that aren't getting solved yet either, it may
> well take a week or two of debugging after it goes in to make it work,
> etc.
>
> The current tree works, for some definition of works. We need to accept
> that on win32 and move forward.
I agree with Marc. "To-day is a good day to die! I say, ship it!"
#ken P-)}
Ken Coar <http://Web.Golux.Com/coar/>
Apache Group member <http://www.apache.org/>
"Apache Server for Dummies" <http://Web.Golux.Com/coar/ASFD/>
Re: [BUG] Win32 assert: sub_canonical_filename() called with
szFile==""
Posted by Marc Slemko <ma...@znep.com>.
No.
We have been far too long with it already, there are other win32 problems
far more important than this that aren't getting solved yet either, it may
well take a week or two of debugging after it goes in to make it work,
etc.
The current tree works, for some definition of works. We need to accept
that on win32 and move forward.
On Thu, 16 Jul 1998, Brian Behlendorf wrote:
> At 02:27 PM 7/16/98 -0600, Marc Slemko wrote:
> >On Thu, 16 Jul 1998, Manoj Kasichainula wrote:
> >
> >> Once we're clear on what we need to support exactly, we can have the
> >> patch ready sometime between today and Monday.
> >
> >No rush, it will not make 1.3.1 anyway.
>
> I am in favor of holding 1.3.1 until mid next week, if a path out of this
> pathname sillyness is on tap.
>
> Brian
>
>
> --=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--
> "Common sense is the collection of prejudices | brian@apache.org
> acquired by the age of eighteen." - Einstein | brian@hyperreal.org
>
Re: [BUG] Win32 assert: sub_canonical_filename() called with
szFile==""
Posted by Brian Behlendorf <br...@hyperreal.org>.
At 02:27 PM 7/16/98 -0600, Marc Slemko wrote:
>On Thu, 16 Jul 1998, Manoj Kasichainula wrote:
>
>> Once we're clear on what we need to support exactly, we can have the
>> patch ready sometime between today and Monday.
>
>No rush, it will not make 1.3.1 anyway.
I am in favor of holding 1.3.1 until mid next week, if a path out of this
pathname sillyness is on tap.
Brian
--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--
"Common sense is the collection of prejudices | brian@apache.org
acquired by the age of eighteen." - Einstein | brian@hyperreal.org
Re: [BUG] Win32 assert: sub_canonical_filename() called with szFile==""
Posted by Ben Laurie <be...@algroup.co.uk>.
Manoj Kasichainula wrote:
>
> On Thu, Jul 16, 1998 at 10:50:16AM -0600, Marc Slemko wrote:
> > On Thu, 16 Jul 1998, snyland@workfire.com wrote:
> >
> > > Um, _please_ take another look at ap_os_canonical_filename where
> > > the code blows away trailing slashes. As of the last cvs snapshot
> > > I have today (19980716130028), it builds but still dies at runtime
> > > when it sees <Directory /> in the default
> >
> > Yes, that is what I said.
> >
> > The workaround I plan for the release is just to remove that from the
> > default config file for now.
>
> We're ready to contribute a patch to fix the problems with
> <Directory />. In fact, we are pretty close to a total
> reimplementation of the win32 canonical filename routines. This
> rewrite also switches from a recursive to iterative implementaion of
> sub_canonical_filename. But, we're not quite sure exactly which cases
> we should have handled in this routine. Can someone enlighten us?
>
> Also, we're not sure we'll be able to support UNC names in these new
> routines yet. But, since UNC paths can be mapped to network drives,
> this shouldn't be a problem.
>
> Once we're clear on what we need to support exactly, we can have the
> patch ready sometime between today and Monday.
There's also been talk of being stricter about what URLs are allowed to
map to paths, and of doing canonicalisation during directory_walk().
Either of these may render your work redundant or incorrect. But that's
no reason not to proceed :-)
Cheers,
Ben.
--
Ben Laurie |Phone: +44 (181) 735 0686| Apache Group member
Freelance Consultant |Fax: +44 (181) 735 0689|http://www.apache.org/
and Technical Director|Email: ben@algroup.co.uk |
A.L. Digital Ltd, |Apache-SSL author http://www.apache-ssl.org/
London, England. |"Apache: TDG" http://www.ora.com/catalog/apache/
WE'RE RECRUITING! http://www.aldigital.co.uk/recruit/
Re: [BUG] Win32 assert: sub_canonical_filename() called with szFile==""
Posted by Ben Laurie <be...@algroup.co.uk>.
Marc Slemko wrote:
>
> On Thu, 16 Jul 1998, Manoj Kasichainula wrote:
> > Also, we're not sure we'll be able to support UNC names in these new
> > routines yet. But, since UNC paths can be mapped to network drives,
> > this shouldn't be a problem.
>
> Mmm. Perhaps. The problem is that there are only a limited number of
> network drives, and some people don't like having to do that.
I seem to remember the reason I originally fixed UNC was because someone
had more UNC drives than they could map, so I'd be upset if UNC support
disappeared.
Cheers,
Ben.
--
Ben Laurie |Phone: +44 (181) 735 0686| Apache Group member
Freelance Consultant |Fax: +44 (181) 735 0689|http://www.apache.org/
and Technical Director|Email: ben@algroup.co.uk |
A.L. Digital Ltd, |Apache-SSL author http://www.apache-ssl.org/
London, England. |"Apache: TDG" http://www.ora.com/catalog/apache/
WE'RE RECRUITING! http://www.aldigital.co.uk/recruit/
Re: [BUG] Win32 assert: sub_canonical_filename() called with szFile==""
Posted by Marc Slemko <ma...@worldgate.com>.
On Thu, 16 Jul 1998, Manoj Kasichainula wrote:
> On Thu, Jul 16, 1998 at 10:50:16AM -0600, Marc Slemko wrote:
> > On Thu, 16 Jul 1998, snyland@workfire.com wrote:
> >
> > > Um, _please_ take another look at ap_os_canonical_filename where
> > > the code blows away trailing slashes. As of the last cvs snapshot
> > > I have today (19980716130028), it builds but still dies at runtime
> > > when it sees <Directory /> in the default
> >
> > Yes, that is what I said.
> >
> > The workaround I plan for the release is just to remove that from the
> > default config file for now.
>
> We're ready to contribute a patch to fix the problems with
> <Directory />. In fact, we are pretty close to a total
> reimplementation of the win32 canonical filename routines. This
> rewrite also switches from a recursive to iterative implementaion of
> sub_canonical_filename. But, we're not quite sure exactly which cases
> we should have handled in this routine. Can someone enlighten us?
Any cases that need to be handled.
I don't think there is anything clearly denoted for what has to be
handled, except that what is handled now is good and what doesn't work now
is good, and... anything that makes sense.
>
> Also, we're not sure we'll be able to support UNC names in these new
> routines yet. But, since UNC paths can be mapped to network drives,
> this shouldn't be a problem.
Mmm. Perhaps. The problem is that there are only a limited number of
network drives, and some people don't like having to do that.
>
> Once we're clear on what we need to support exactly, we can have the
> patch ready sometime between today and Monday.
No rush, it will not make 1.3.1 anyway.
Re: [BUG] Win32 assert: sub_canonical_filename() called with szFile==""
Posted by Manoj Kasichainula <ma...@raleigh.ibm.com>.
On Thu, Jul 16, 1998 at 10:50:16AM -0600, Marc Slemko wrote:
> On Thu, 16 Jul 1998, snyland@workfire.com wrote:
>
> > Um, _please_ take another look at ap_os_canonical_filename where
> > the code blows away trailing slashes. As of the last cvs snapshot
> > I have today (19980716130028), it builds but still dies at runtime
> > when it sees <Directory /> in the default
>
> Yes, that is what I said.
>
> The workaround I plan for the release is just to remove that from the
> default config file for now.
We're ready to contribute a patch to fix the problems with
<Directory />. In fact, we are pretty close to a total
reimplementation of the win32 canonical filename routines. This
rewrite also switches from a recursive to iterative implementaion of
sub_canonical_filename. But, we're not quite sure exactly which cases
we should have handled in this routine. Can someone enlighten us?
Also, we're not sure we'll be able to support UNC names in these new
routines yet. But, since UNC paths can be mapped to network drives,
this shouldn't be a problem.
Once we're clear on what we need to support exactly, we can have the
patch ready sometime between today and Monday.
--
Manoj Kasichainula - manojk@raleigh.ibm.com
IBM - Research Triangle Park, NC
ADTI, IBM Apache Development Team
Re: [BUG] Win32 assert: sub_canonical_filename() called with szFile==""
Posted by Marc Slemko <ma...@worldgate.com>.
On Thu, 16 Jul 1998, snyland@workfire.com wrote:
>
>
> Marc Slemko wrote:
>
> > On Thu, 16 Jul 1998, snyland@workfire.com wrote:
> >
> > > Um, _please_ take another look at ap_os_canonical_filename where the code blows
> > > away trailing slashes. As of the last cvs snapshot I have today (19980716130028), it
> > > builds but still dies at runtime when it sees <Directory /> in the default
> >
> > Yes, that is what I said.
> >
> > The workaround I plan for the release is just to remove that from the
> > default config file for now.
> >
>
> Oh. Ok. I noticed it hadn't been changed in that snapshot. You know better than I if
> that is a reasonable workaround that won't mess up people who plan to actually use your
> server in the field (so to speak). Seems a pretty big stretch not to allow anyone to have
> a <Directory /> section in any of their conf files. Whatever. Let me know if I can help.
> I feel like I am just criticizing here. My apologies.
If it could be fixed it would.
No one knows how or cares or has thing time (or some combination of those
three) to fix it at this moment.
>
> BTW, does _anyone_ use the current-testers mailing list? I signed up, but I never get
> anything from it. That's probably a more appropriate forum for me since I have not been
> contributing solutions.
The -testers lists are somewhat new and people are still getting used to
them, but the basic idea is that they are used before releaes.
So I sent a message the other day to stable-testers asking people to test
1.3.1-dev. We aren't releasing any betas at the moment, so don't really
have anything for current-testers...
They are also moderated.
Re: [BUG] Win32 assert: sub_canonical_filename() called with szFile==""
Posted by "snyland@workfire.com" <sn...@workfire.com>.
Marc Slemko wrote:
> On Thu, 16 Jul 1998, snyland@workfire.com wrote:
>
> > Um, _please_ take another look at ap_os_canonical_filename where the code blows
> > away trailing slashes. As of the last cvs snapshot I have today (19980716130028), it
> > builds but still dies at runtime when it sees <Directory /> in the default
>
> Yes, that is what I said.
>
> The workaround I plan for the release is just to remove that from the
> default config file for now.
>
Oh. Ok. I noticed it hadn't been changed in that snapshot. You know better than I if
that is a reasonable workaround that won't mess up people who plan to actually use your
server in the field (so to speak). Seems a pretty big stretch not to allow anyone to have
a <Directory /> section in any of their conf files. Whatever. Let me know if I can help.
I feel like I am just criticizing here. My apologies.
BTW, does _anyone_ use the current-testers mailing list? I signed up, but I never get
anything from it. That's probably a more appropriate forum for me since I have not been
contributing solutions.
> > access.conf. If you release it this will make a lot of Win32 guys very unhappy, even
> > if you do document it. Isn't there anything that can be done about this for 1.3.1?
> > Basically it doesn't run out of the box. :-(
> >
> >
Re: [BUG] Win32 assert: sub_canonical_filename() called with szFile==""
Posted by Marc Slemko <ma...@worldgate.com>.
On Thu, 16 Jul 1998, snyland@workfire.com wrote:
> Um, _please_ take another look at ap_os_canonical_filename where the code blows
> away trailing slashes. As of the last cvs snapshot I have today (19980716130028), it
> builds but still dies at runtime when it sees <Directory /> in the default
Yes, that is what I said.
The workaround I plan for the release is just to remove that from the
default config file for now.
> access.conf. If you release it this will make a lot of Win32 guys very unhappy, even
> if you do document it. Isn't there anything that can be done about this for 1.3.1?
> Basically it doesn't run out of the box. :-(
>
> Marc Slemko wrote:
>
> > On Tue, 14 Jul 1998, Ben Laurie wrote:
> >
> > > > > This runs into problems in ap_os_canonical_filename where the code now blows
> > > > > away trailing slashes.
> > > > >
> > > > > // Finally, a trailing slash(es) screws thing, so blow them away
> > > > > for(nSlashes=0 ; d > b2 && d[-1] == '\\' ; --d,++nSlashes)
> > > > > ;
> > > > > /* XXXX this breaks '/' and 'c:/' cases */
> > > > > *d='\0';
> > > >
> > > > Yup. And I did fix that part to leave "/" and "c:/" (where c is any
> > > > drive; drives aren't restricted to letters, are they? letters and a few
> > > > symbols I thought... although perhaps that was only DOS) (but didn't
> > > > commit the fix), but it doesn't do much good because they still aren't
> > > > applied properly, so then you could have the section but it would be
> > > > ignored, which is a bad thing.
> > >
> > > Under what circumstances is it ignored?
> >
> > All circumstances as far as I am aware.
> >
> > At the moment, if you try a "<Directory c:/>" or "<Directory />" it barfs
> > with an assert because it strips the trailing '/'.
> >
> > If you fix the code so it doesn't strip tailing '/'s in that case, then
> > the sections just don't appear to match anything. Obviously, there is
> > some other bug in there. I think that not stripping the trailing '/'s off
> > such entries is the right thing to do, but it is academic at this point
> > because someone has to go through all the steps to see why it doesn't work
> > and what needs to be done to make it work. But not for 1.3.1.
>
>
>
Re: [BUG] Win32 assert: sub_canonical_filename() called with szFile==""
Posted by "snyland@workfire.com" <sn...@workfire.com>.
Um, _please_ take another look at ap_os_canonical_filename where the code blows
away trailing slashes. As of the last cvs snapshot I have today (19980716130028), it
builds but still dies at runtime when it sees <Directory /> in the default
access.conf. If you release it this will make a lot of Win32 guys very unhappy, even
if you do document it. Isn't there anything that can be done about this for 1.3.1?
Basically it doesn't run out of the box. :-(
Marc Slemko wrote:
> On Tue, 14 Jul 1998, Ben Laurie wrote:
>
> > > > This runs into problems in ap_os_canonical_filename where the code now blows
> > > > away trailing slashes.
> > > >
> > > > // Finally, a trailing slash(es) screws thing, so blow them away
> > > > for(nSlashes=0 ; d > b2 && d[-1] == '\\' ; --d,++nSlashes)
> > > > ;
> > > > /* XXXX this breaks '/' and 'c:/' cases */
> > > > *d='\0';
> > >
> > > Yup. And I did fix that part to leave "/" and "c:/" (where c is any
> > > drive; drives aren't restricted to letters, are they? letters and a few
> > > symbols I thought... although perhaps that was only DOS) (but didn't
> > > commit the fix), but it doesn't do much good because they still aren't
> > > applied properly, so then you could have the section but it would be
> > > ignored, which is a bad thing.
> >
> > Under what circumstances is it ignored?
>
> All circumstances as far as I am aware.
>
> At the moment, if you try a "<Directory c:/>" or "<Directory />" it barfs
> with an assert because it strips the trailing '/'.
>
> If you fix the code so it doesn't strip tailing '/'s in that case, then
> the sections just don't appear to match anything. Obviously, there is
> some other bug in there. I think that not stripping the trailing '/'s off
> such entries is the right thing to do, but it is academic at this point
> because someone has to go through all the steps to see why it doesn't work
> and what needs to be done to make it work. But not for 1.3.1.
Re: [BUG] Win32 assert: sub_canonical_filename() called with szFile==""
Posted by Alexei Kosut <ak...@leland.Stanford.EDU>.
On Tue, 14 Jul 1998, Marc Slemko wrote:
> At the moment, if you try a "<Directory c:/>" or "<Directory />" it barfs
> with an assert because it strips the trailing '/'.
>
> If you fix the code so it doesn't strip tailing '/'s in that case, then
> the sections just don't appear to match anything. Obviously, there is
> some other bug in there. I think that not stripping the trailing '/'s off
> such entries is the right thing to do, but it is academic at this point
> because someone has to go through all the steps to see why it doesn't work
> and what needs to be done to make it work. But not for 1.3.1.
Yeah. It strikes me that os_canonical_filename() is problematic.
Especially the whole deal with sub_canonical_filename(). It strikes me
that os_canonical_filename() is called (I'm ignoring the calls that
canonicalize configuration directives for now) in directory_walk(), just
before it... well... walks through the directories. I'm thinking it might
be a better idea to remove all the directory-munging stuff from
os_canonical_filename(), because directory_walk() does it too, and replace
it with a os_canonical_path(char *path, char *file), where path is a
pathname that's already canonicalized except for the last part, which file
points to. directory_walk() can call this as it goes through each path
section, and the canonicalization work gets done for free.
And it won't mess with path info, because directory_walk is also where we
determine what path_info is, and it doesn't try to walk there.
*shrug*
-- Alexei Kosut <ak...@stanford.edu> <http://www.stanford.edu/~akosut/>
Stanford University, Class of 2001 * Apache <http://www.apache.org> *
Re: [BUG] Win32 assert: sub_canonical_filename() called with szFile==""
Posted by Marc Slemko <ma...@znep.com>.
On Tue, 14 Jul 1998, Ben Laurie wrote:
> > > This runs into problems in ap_os_canonical_filename where the code now blows
> > > away trailing slashes.
> > >
> > > // Finally, a trailing slash(es) screws thing, so blow them away
> > > for(nSlashes=0 ; d > b2 && d[-1] == '\\' ; --d,++nSlashes)
> > > ;
> > > /* XXXX this breaks '/' and 'c:/' cases */
> > > *d='\0';
> >
> > Yup. And I did fix that part to leave "/" and "c:/" (where c is any
> > drive; drives aren't restricted to letters, are they? letters and a few
> > symbols I thought... although perhaps that was only DOS) (but didn't
> > commit the fix), but it doesn't do much good because they still aren't
> > applied properly, so then you could have the section but it would be
> > ignored, which is a bad thing.
>
> Under what circumstances is it ignored?
All circumstances as far as I am aware.
At the moment, if you try a "<Directory c:/>" or "<Directory />" it barfs
with an assert because it strips the trailing '/'.
If you fix the code so it doesn't strip tailing '/'s in that case, then
the sections just don't appear to match anything. Obviously, there is
some other bug in there. I think that not stripping the trailing '/'s off
such entries is the right thing to do, but it is academic at this point
because someone has to go through all the steps to see why it doesn't work
and what needs to be done to make it work. But not for 1.3.1.
Re: [BUG] Win32 assert: sub_canonical_filename() called with szFile==""
Posted by Ben Laurie <be...@algroup.co.uk>.
Marc Slemko wrote:
>
> On Tue, 14 Jul 1998, snyland@workfire.com wrote:
>
> >
> >
> > Marc Slemko wrote:
> >
> > > On Tue, 14 Jul 1998, Martin Kraemer wrote:
> > >
> > > > A colleague of mine just tried a compilation of today's apache-1.3.1-dev
> > > > under WinNT. He reports no major compilation problems, but
> > > > runs into an assertion in os/win32/util_win32.c line 24 because
> > > > sub_canonical_filename() -after being called several times successfully-
> > > > is finally called with an argument of szFile == "" (empty string).
> > >
> > > The problem is due to having a path in the form "/" or "c:/" in your
> > > config file in a directory section or something. Remove that and you
> > > should be happier.
> > >
> >
> > Confirmed. The default access.conf has a directory section <Directory />.
> > This runs into problems in ap_os_canonical_filename where the code now blows
> > away trailing slashes.
> >
> > // Finally, a trailing slash(es) screws thing, so blow them away
> > for(nSlashes=0 ; d > b2 && d[-1] == '\\' ; --d,++nSlashes)
> > ;
> > /* XXXX this breaks '/' and 'c:/' cases */
> > *d='\0';
>
> Yup. And I did fix that part to leave "/" and "c:/" (where c is any
> drive; drives aren't restricted to letters, are they? letters and a few
> symbols I thought... although perhaps that was only DOS) (but didn't
> commit the fix), but it doesn't do much good because they still aren't
> applied properly, so then you could have the section but it would be
> ignored, which is a bad thing.
Under what circumstances is it ignored?
Cheers,
Ben.
--
Ben Laurie |Phone: +44 (181) 735 0686| Apache Group member
Freelance Consultant |Fax: +44 (181) 735 0689|http://www.apache.org/
and Technical Director|Email: ben@algroup.co.uk |
A.L. Digital Ltd, |Apache-SSL author http://www.apache-ssl.org/
London, England. |"Apache: TDG" http://www.ora.com/catalog/apache/
WE'RE RECRUITING! http://www.aldigital.co.uk/recruit/
Re: [BUG] Win32 assert: sub_canonical_filename() called with szFile==""
Posted by Marc Slemko <ma...@worldgate.com>.
On Tue, 14 Jul 1998, snyland@workfire.com wrote:
>
>
> Marc Slemko wrote:
>
> > On Tue, 14 Jul 1998, Martin Kraemer wrote:
> >
> > > A colleague of mine just tried a compilation of today's apache-1.3.1-dev
> > > under WinNT. He reports no major compilation problems, but
> > > runs into an assertion in os/win32/util_win32.c line 24 because
> > > sub_canonical_filename() -after being called several times successfully-
> > > is finally called with an argument of szFile == "" (empty string).
> >
> > The problem is due to having a path in the form "/" or "c:/" in your
> > config file in a directory section or something. Remove that and you
> > should be happier.
> >
>
> Confirmed. The default access.conf has a directory section <Directory />.
> This runs into problems in ap_os_canonical_filename where the code now blows
> away trailing slashes.
>
> // Finally, a trailing slash(es) screws thing, so blow them away
> for(nSlashes=0 ; d > b2 && d[-1] == '\\' ; --d,++nSlashes)
> ;
> /* XXXX this breaks '/' and 'c:/' cases */
> *d='\0';
Yup. And I did fix that part to leave "/" and "c:/" (where c is any
drive; drives aren't restricted to letters, are they? letters and a few
symbols I thought... although perhaps that was only DOS) (but didn't
commit the fix), but it doesn't do much good because they still aren't
applied properly, so then you could have the section but it would be
ignored, which is a bad thing.
Sigh.
Re: [BUG] Win32 assert: sub_canonical_filename() called with szFile==""
Posted by "snyland@workfire.com" <sn...@workfire.com>.
Marc Slemko wrote:
> On Tue, 14 Jul 1998, Martin Kraemer wrote:
>
> > A colleague of mine just tried a compilation of today's apache-1.3.1-dev
> > under WinNT. He reports no major compilation problems, but
> > runs into an assertion in os/win32/util_win32.c line 24 because
> > sub_canonical_filename() -after being called several times successfully-
> > is finally called with an argument of szFile == "" (empty string).
>
> The problem is due to having a path in the form "/" or "c:/" in your
> config file in a directory section or something. Remove that and you
> should be happier.
>
Confirmed. The default access.conf has a directory section <Directory />.
This runs into problems in ap_os_canonical_filename where the code now blows
away trailing slashes.
// Finally, a trailing slash(es) screws thing, so blow them away
for(nSlashes=0 ; d > b2 && d[-1] == '\\' ; --d,++nSlashes)
;
/* XXXX this breaks '/' and 'c:/' cases */
*d='\0';
> Yes, it is in the default config file. That is one of the things that has
> to be fixed before 1.3.1.
Yes please. This will seem very serious & incomprehensible to a lot of Win32
users.
Re: [BUG] Win32 assert: sub_canonical_filename() called with szFile==""
Posted by Marc Slemko <ma...@worldgate.com>.
On Tue, 14 Jul 1998, Martin Kraemer wrote:
> A colleague of mine just tried a compilation of today's apache-1.3.1-dev
> under WinNT. He reports no major compilation problems, but
> runs into an assertion in os/win32/util_win32.c line 24 because
> sub_canonical_filename() -after being called several times successfully-
> is finally called with an argument of szFile == "" (empty string).
The problem is due to having a path in the form "/" or "c:/" in your
config file in a directory section or something. Remove that and you
should be happier.
Yes, it is in the default config file. That is one of the things that has
to be fixed before 1.3.1.