From: Nicholas Miell <nmiell@comcast.net>
To: Christoph Hellwig <hch@infradead.org>
Cc: Barry Naujok <bnaujok@sgi.com>,
"xfs@oss.sgi.com" <xfs@oss.sgi.com>,
linux-fsdevel@vger.kernel.org, urban@svenskatest.se
Subject: Re: RFC: Case-insensitive support for XFS
Date: Fri, 05 Oct 2007 11:52:18 -0700 [thread overview]
Message-ID: <1191610338.2695.8.camel@entropy> (raw)
In-Reply-To: <20071005154442.GA6432@infradead.org>
On Fri, 2007-10-05 at 16:44 +0100, Christoph Hellwig wrote:
> [Adding -fsdevel because some of the things touched here might be of
> broader interest and Urban because his name is on nls_utf8.c]
>
> On Fri, Oct 05, 2007 at 11:57:54AM +1000, Barry Naujok wrote:
> >
> > On it's own, linux only provides case conversion for old-style
> > character sets - 8 bit sequences only. A lot of distos are
> > now defaulting to UTF-8 and Linux NLS stuff does not support
> > case conversion for any unicode sets.
>
> The lack of case tables in nls_utf8.c defintively seems odd to me.
> Urban, is there a reason for that? The only thing that comes to
> mind is that these tables might be quite large.
>
Case conversion in Unicode is locale dependent. The legacy 8-bit
character encodings don't code for enough characters to run into the
ambiguities, so they can get away with fixed case conversion tables.
Unicode can't.
I'd point you to the Unicode technical report which explains how to do
it, but unicode.org seems to be offline right now.
> > NTFS in Linux also implements it's own dcache and NTFS also
>
> ^^^^^^^ dentry operations?
>
> > stores its unicode case table on disk. This allows the filesystem
> > to migrate to newer forms of Unicode at the time of formatting
> > the filesystem. Eg. Windows Vista now supports Unicode 5.0
> > while older version would support an earlier version of
> > Unicode. Linux's version of NTFS case table is implemented
> > in fs/ntfs/upcase.c defined as default_upcase.
>
> Because ntfs uses 16bit wide chars it prefers to use it's own tables.
> I'm not sure it's a that good idea.
Well, Windows uses those on-disk tables, so the Linux driver has to
also. I don't see how that's a bad idea or any way to not do it and
remain compatible.
--
Nicholas Miell <nmiell@comcast.net>
next prev parent reply other threads:[~2007-10-05 18:52 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <op.ty6361ut3jf8g2@pc-bnaujok.melbourne.sgi.com>
[not found] ` <op.tzpbqspl3jf8g2@pc-bnaujok.melbourne.sgi.com>
2007-10-05 15:44 ` RFC: Case-insensitive support for XFS Christoph Hellwig
2007-10-05 18:52 ` Nicholas Miell [this message]
2007-10-08 5:07 ` Barry Naujok
2007-10-08 5:44 ` Nicholas Miell
2007-10-08 6:17 ` Barry Naujok
2007-10-08 7:00 ` Barry Naujok
2007-10-10 2:27 ` Barry Naujok
2007-10-05 19:10 ` Anton Altaparmakov
2007-10-06 6:37 ` Brad Boyer
2007-10-06 13:00 ` Anton Altaparmakov
2007-10-08 0:43 ` Barry Naujok
2007-10-08 0:33 ` Barry Naujok
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1191610338.2695.8.camel@entropy \
--to=nmiell@comcast.net \
--cc=bnaujok@sgi.com \
--cc=hch@infradead.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=urban@svenskatest.se \
--cc=xfs@oss.sgi.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).