httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Brian Havard" <bri...@kheldar.apana.org.au>
Subject RE: cvs commit: apache-1.3/src/os/win32 util_win32.c
Date Tue, 26 Sep 2000 00:49:13 GMT
On Sun, 24 Sep 2000 21:46:54 -0500, William A. Rowe, Jr. wrote:

>> From: Brian Havard [mailto:brianh@silk.apana.org.au]
>> Sent: Friday, July 10, 2893 5:44 PM

>> > What I've done is bypassed most of this for the /, //, //server to
>> > actually accept these elements without any sort of find test.  We
>> > don't really know if //server is legit until we test 
>> //server/share/.
>> > Now we accept all these flavors, although they consitute an 
>> incomplete
>> > path spec.
>> 
>> I don't think this is right. //server may not be legit but it IS
>> canonical. / isn't, it represents the root of whatever drive 
>> is current
>> so it shouldn't be returned.
>
>No... this has been discussed on the list.
>
>/ isn't cantonical on WIN32/OS2/NETWARE, since any of the three may
>have a volume designation (other than current volume) prefixed with vol:
>
>However... / is considered by the list to be the 'root', or default
>volume.  I proposed an alternate syntax (<DirectoryDefault> ?  Whatever)
>and no one grinned.  It seems that this list prefers that '/' is legit.

I'm not saying that / shouldn't match everything. I'm saying that this
special casing doesn't belong in ap_os_canonical_filename(), it belongs in
<Directory> directive processing.



>I would consider special case handling of '/', but that's a bigger patch
>than I orginally planned to bite.  I would rather see us play the
><DirectoryDefault> game if we are going to play over there.
>
>> >   The ap_os_canonical_filename() stuff in util_[win32|os2|netware].c
>> > is very different right now, and OS2 and WIN32 could probably merge.
>> > I believe OS2 also supports blehblehbleh.x, and either 
>> blehbl~1.x or 
>> > blehbleh.x flavors of short names. 
>> 
>> No, it doesn't, at least not on the file systems usually used 
>> (HPFS, JFS, FAT). Once you start allowing for other file systems 
>> anything is possible including case sensitivity. Also, OS/2 has a 
>> single API call that takes care of almost all canonicalization (the 
>> DosQueryPathInfo() call) which makes much of what's done in the 
>> win32 code unnecessary.  Note I'm lowercasing the //machine/share
>> part for consistency of comparisons.
>
>I'm jealous :-)  And I agree with you.
>
>> > It seems very early on that NT 
>> > had choices in the config for how short names could be composed.  
>> > Since OS2 also allows Novell client access, and Novell would use 
>> > blehbleh.x, I was not happy with simply expanding shortnames in the 
>> > *~* case.  Now we always case-correct and expand shortnames in 
>> > ap_os_systemcase_filename.
>> 
>> Yes true, but OS/2 can also access NT, NFS & Samba volumes. 
>
>So all of the problems above apply, yet DosQueryPathInfo() should 
>resolve all these cases, no?

No, the DosQueryPathInfo() call doesn't resolve long/short file name
problems, it doesn't even access the file system. It just does a
relative->absolute path mapping, also taking care of trailing '.'s or
spaces.

I'm not sure if an OS/2 process can access a file via its short file names
when on an NT share, I'll have to check.



>> >   ap_os_canonical_filename() (http_core.c:1454), for OS2/NETWARE,
>> > should really sit in their respective util_[OS2|NETWARE].c files,
>> > if they don't already.
>> 
>> http_core.c:1454 has a call TO ap_os_canonical_filename() if I remember
>> right. I can't actually look at the code right now as I just had my main
>> hard disk die on me (writing this from my laptop).
>
>Sorry to hear... and I'd agree that makes more sense...
>
>looking...
>
>Slid down to 1463, but yup, you are correct.  If you would rather handle
>the <Directory /> case as a pseudo-<DirectoryDefault>, we can recode:
>
>	cmd->path = ap_os_canonical_filename(cmd->pool, cmd->path);
>
>as:
>
>	if (strcmp(cmp->path, "/") != 0)    
>	    cmd->path = ap_os_canonical_filename(cmd->pool, cmd->path);
>
>and remove the "/" acceptability from ap_os_canonical_filename.

Yes, that's what I'm thinking.

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


Mime
View raw message