Case insensitive file systems and caching mechanisms.

[Graham Dumpleton <gr...@gmail.com>]

On Windows where a case insensitive, but case preserving file system
is used, my understanding is that one can use the
APR_FILEPATH_TRUENAME option to apr_filepath_merge() to convert a file
system path into one which has case set to the actual values. Ie.,
documentation says:

/** Resolve the true case of existing directories and file elements
 * of addpath, (resolving any aliases on Win32) and append a proper
 * trailing slash if a directory
 */
#define APR_FILEPATH_TRUENAME       0x20

This might be used on r->filename where one is using some form of
Alias directive where part of the URL is used to match an actual
physical file.

  Alias /some/url/ /some/path/

The reason for doing this would be where r->filename is being used as
a key into some form of caching system and where you most definitely
want /some/path/file.txt and /some/path/FILE.txt to resolve to the
same entry in the caching system. Ie., you don't want what case
someone may have used in the URL beyond /some/url/ to result in
multiple entries in the cache where they all actually may be the same
file.

This is all well and good on Windows, but on MacOSX one also has a
case insensitive but case preserving filesystem in the form of HFS and
HFS+. On MacOSX though, the apr_filepath_merge() follows the UNIX
behaviour where APR_FILEPATH_TRUENAME doesn't actually do anything and
the case in the path is left as it was in the input.

Thus, on MacOSX one can end up with multiple entries in such a caching
system for what is the same actual file.

Where a caching system simply cannot have such duplicates, how do
people deal with this? Is there something in APR that can be used as
so far I haven't been able to find anything? I also need a solution
for Apache 1.3 as well which means something in APR will be of no use
to me for that case.

Possible approaches I can see one taking are as follows.

1. For MacOSX assume that file systems will be case insensitive and
lower case r->filename before using it as the key in the caching
system. To cope with possibility that someone may use UFS, or some
time down the track ZFS, provide a directive which could be used to
indicate that a directory/file system is actually case sensitive. Ie.,
push it back into user to do manual configuration where required.

2. Do a second apr_stat() call on r->filename but where the case of
the path is changed for the last filename component of the path. If
this resolves to the same inode as r->finfo then can assume case
insensitive file system and lower case path when used as key.

3. Use some other call in MacOSX, that I haven't yet been able to
find, which can tell me whether the file system a path falls in is
case insensitive.

Anyone got any suggestions as to what would be the best way of working
it out, or how better to handle this issue with case insensitive file
systems on MacOSX.

Graham

Re: Case insensitive file systems and caching mechanisms.

[Giuliano Gavazzi <de...@humph.com>]

On 15 Jun 2007, at 07:02, Graham Dumpleton wrote:

> This is all well and good on Windows, but on MacOSX one also has a
> case insensitive but case preserving filesystem in the form of HFS and
> HFS+. On MacOSX though, the apr_filepath_merge() follows the UNIX
> behaviour where APR_FILEPATH_TRUENAME doesn't actually do anything and
> the case in the path is left as it was in the input.
[...]
>
> 1. For MacOSX assume that file systems will be case insensitive and
> lower case r->filename before using it as the key in the caching
> system. To cope with possibility that someone may use UFS, or some
> time down the track ZFS, provide a directive which could be used to
> indicate that a directory/file system is actually case sensitive. Ie.,
> push it back into user to do manual configuration where required.

let me just point out that it's quite some time since on MacOSX you  
can use a case preserving Apple_HFSX.
I like the manual configuration idea, where you should also be able  
to configure a default value.
Giuliano