Subject: Re: Mount option to ignore case
To: Johan Ihren <johani@autonomica.se>
From: Bill Studenmund <wrstuden@netbsd.org>
List: tech-kern
Date: 04/03/2002 09:43:20
On 3 Apr 2002, Johan Ihren wrote:

> Bill Studenmund <wrstuden@netbsd.org> writes:
>
> > > a) choose one of the mappings and lose the other(s).
> > >
> > > b) decide that "i" cannot be case converted for the purposes of
> > >    filename comparision. That would hurt quite badly, since we *can*
> > >    case convert "i" right now.
> > >
> > > c) make everything *really* ugly and only allow characters from the
> > >    present locale when creating new files (so that it is possible to
> > >    know that all characters are from the same locale). Not even worth
> > >    thinking about.
> >
> > d) figure out a way for different users to use different tables (locale
> > specific)
>
> Urk. We're talking about identifiers here. Identifiers should have
> exact matching rules or everything becomes very strange. To my mind
> having that type of fuzzy locale-dependent filename matching would be
> almost like (contrived example follows) having locale-dependent
> variable *names* in the src to a program that I run.

Right. We're talking about identifiers. :-)

The reason I'm comfortable with local-specific matching is we've turned on
case-insensitivity, which is a local-specific concept. If you type the
exact name in, you will always get the right match (*). It's only when you
type a close-but-not-quite name that the locale becomes important. But
since excatly what is "close-but-not-quite" differes with locale, that
makes sense. :-)

Also, how often do folks change locales? While a system may have multiple
locales in use at once, I expect each user will choose one and stick with
it. So that user will have a fairly consistent environment, and any name
quirks will be stable and readily known.

> > e) don't bother with case insensitivity now since it's such a mess
>
> Much better.

Probably the best for now.

> If you can have two votes, then so can I ;-) My second vote would then
> obviously be for (e), which makes this the dominant alternative. But
> I'm not convinced that everyone (or even anyone) else would agree with
> that.

:-)

The other thing I was wondering is what do other OSs do? We should look at
prior art, and see how well those choices worked out.

Take care,

Bill