Um, something I just noticed.  HFS+ filesystems.

I haven't played with it much in a LONG time, but the last time I did
anything with an HFS filesystem, the '/' character was valid in a
filename.  How did we work around this?

On Sat, 30 Mar 2002, Bill Studenmund wrote:

# Date: Sat, 30 Mar 2002 18:06:13 -0800 (PST)
# From: Bill Studenmund <wrstuden@netbsd.org>
# To: Reinoud Zandijk <reinoud@netbsd.org>
# Cc: Jukka Marin <jmarin@pyy.jmp.fi>, tech-kern@netbsd.org
# Subject: Re: Mount option to ignore case
#
# 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
#
#
#


				--*greywolf;
--
NetBSD: Scalability Does Matter.