Mailing-List: contact new-httpd-help@apache.org; run by ezmlm
Precedence: bulk
Reply-To: new-httpd@apache.org
From: "William A. Rowe, Jr." <wrowe@lnd.com>
To: <new-httpd@apache.org>
Subject: RE: ap_os_is_filename_valid calls.
Date: Tue, 16 May 2000 08:18:16 -0500
Message-ID: <000201bfbf39$607f9bc0$345985d0@corecomm.net>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
In-Reply-To: <01d301bfbf31$79bfaa10$c1e01b09@raleigh.ibm.com>
Importance: Normal

I've looked at this and ment to fix... if someone beats me to it
though;

We can drop all the device driver name test garbage.  The file
attribute value 0x80 flags the file as a 'virtual', or something
that we never want apache to test.  Ergo... walking the list of
directories and names, if we stat with an 0x80, we are in the
wrong place and need to fail.  NUL, CON, LPTx etc all return this
value, since the ancient days of MS-DOS.

Bill

> -----Original Message-----
> From: Bill Stoddard [mailto:stoddard@raleigh.ibm.com]
> Sent: Tuesday, May 16, 2000 7:23 AM
> To: new-httpd@apache.org
> Subject: Re: ap_os_is_filename_valid calls.
> 
> 
> 
> > On Mon, May 15, 2000 at 08:06:47AM -0400, Bill Stoddard wrote:
> > > I think canonical_filename is very application specific 
> and does not
> > > belong in APR.
> >
> > Hmmm. Actually, I can see it being generally useful.
> >
> > Let's take an app on the complete opposite side of the map from
> > Apache: say, a word processor. It needs to know the last 4 files
> > edited so it can present a history. Now, wouldn't it be 
> nice if those
> > 4 files were actually distinct? demonical_filename can be useful in
> > this case, too.
> >
> > Any app that needs to check if two filenames are intended 
> to point to
> > the same file can use this (or a variant of what we have, 
> anyway). So
> > it seems that APR would be a good place for it.
> 
> Have you looked at what all ap_os_case_canonical_filename 
> does in src/os/win32/util.c?  I
> don't think the word processor would need to spend cycles 
> checking for all these cases.  I
> don't have strong thoughts on it one way or the other, just 
> seems we have bigger fish to
> fry (like getting the buildconf, libtool, etc. fixed).
> 
> Bill
>