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