On Sat, 30 Mar 2002, Reinoud Zandijk wrote:

> On Sat, Mar 30, 2002 at 10:01:49AM +0200, Jukka Marin wrote:
> > On Fri, Mar 29, 2002 at 12:38:18PM -0800, Bill Studenmund wrote:
>
> > > The problem with this is that there is no easy way to do this. It came up
> > > at the IETF meeting. The problem is that to propery do this comparison,
> > > you need locale information. One main example involves the traditional and
> > > simplified kanji characters in the unicode set. In many Chineese locales,
> > > they are considered equivalent. But in Japanese locales, they are not.
> >
> > AFAIK, amiga and msdos never supported unicode or kanji.  I don't think Amiga
> > had other charsets than 8859-1.  Msdos had only one charset, too (but it
> > was different from the one used by windoze, of course).

(This is more for Jukka)

Oh, I forgot to mention this in an earlier EMail: "So?"

We also have ntfs which, as I recall from the discussions around unicode
support for it, has unicode support in it. We want hfs+, which is unicode.
We are going to need to support unicode file systems.

As long as the kernel preserves case, then we don't care really if the
file names are US-ASCII, ISO-8859-X, or UNICODE. For the same name in, we
create/find the same file each time. If we add case insensitivity, then we
need to start worrying about what those bytes really are.

I think the comments about amiga and msdos were more around the fact what
these fs's do can be seen as a silent enforcememnt of this flag.

> What about a filesystem specific callback function for name comparison?
> then the filesystems who would want such a comparisation done in one way or
> another can do it their way... another option would offcource be to specify
> a standard comparisation method in the filingsystems structure given to the
> kernel.... then `most common' ones can be shared.

We already have a filesystem specific callback function, which is called
VOP_LOOKUP().

I think a library or group of functions to handle the comparison would be
good.

Take care,

Bill