httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Greg Stein <>
Subject Re: ap_os_canonical_filename() and friends
Date Fri, 09 Jun 2000 09:04:01 GMT
Simple answer? I'd say that it is simply a mess and nobody really knows the
answer here. (beyond reading the source)

The three functions plus that macro seem *way* overly complex. IMO, please
feel free to use your discretion in cleaning it all up. Certainly can't make
it more obtuse than it is today :-)


On Thu, Jun 08, 2000 at 06:43:16PM -0700, Wilfredo Sánchez wrote:
>   I need to (finally) implement case handling for Mac OS X, where you may  
> or may not have your document root on an case-insensitive volume.  Given  
> that OS X will likely ship before using 2.0 is feasible, I'm starting with  
> 1.3 and I'll port to 2.0 afterwards.
>   I have a couple of questions...  First, I'm trying to figure out the  
> differences between these functions:
> 	ap_os_canonical_filename()
> 	ap_os_case_canonical_filename()
> 	ap_os_systemcase_filename()
>   If ap_os_case_canonical_filename() is supposed to preserve the input  
> case, then what is its role?
>   Say I have a file /FooBar on disk, and I'm looking for a file "/fooBAR".  
>  What's the result?  Let's solve for HFS+ (case insensitive but  
> preserving), DOS FAT (case insensitive), and UFS (case sensitive).  I think  
> I can fill in for ap_os_canonical_filename(), but I don't know about the  
> rest:
> 		Input		ap_ocf()		ap_occf()		 
> ap_osf()
> HFS+		/fooBAR		/FooBar		?			?
> FAT		/fooBAR		/foobar		?			?
> UFS		/fooBAR		/fooBAR		/fooBAR		/fooBAR
>   Second, we also have a macro CASE_BLIND_FILESYSTEM, which, given the  
> above functions, seems broken.  CASE_BLIND_FILESYSTEM us used by the proxy  
> and autoindex modules, which I'd guess should be using the above functions,  
> no?
> 	-Fred
> Wilfredo Sanchez,
> Open Source Engineering Lead
> Apple Computer, Inc., Core Operating System Group
> 1 Infinite Loop, Cupertino, CA 94086, 408.974-5174

Greg Stein,

View raw message