Re: [PATCH] Full NLS support for HFS (classic) filesystem

[Roman Zippel <zippel@linux-m68k.org>]

Hi,

On Tue, 31 May 2005, Pavel Fedin wrote:

>  This is my line. If "codepage" option is added in the future then the line
> would look like:
> 
> /dev/cdrom /mnt/cdrom iso9660,udf,hfsplus,hfs
> user,noauto,iocharset=koi8-r,codepage=866,hfscodepage=10007 0 0

Use different mount points. This is not a reason to create a lot of 
different options all doing the same.

> > Why do you build the extra translation tables? I'm not relly convinced this
> > is a kernel problem at all, but doing it more like fat would be more
> > acceptable (maybe just with some more sane defaults).
> 
>  I tried this in the beginning of my work and failed. As i can see some
> special tricky algorythm is used in order to find a file by name which depends
> on actual character code values (there are "<" and ">" conditions). It does
> not use string comparison at all. This algorythm requires the filename to be
> translated back from UNIX encoding to Mac encoding. I just can't apply another
> algorythm like "list all names in the directory, convert every name to UNIX
> encoding and compare", HFS simply does not behave this way.

This is not HFS specific problem, you have this problem with any fs using 
nls. fat does the comparison using the translated names, but that just 
means it may find the wrong file instead of no file.

>  Extra tables built on the fly ensure that every character in "codepage"  has
> its own unique equivalent in "iocharset", some equivalents are "invented" by
> marking all unmapped characters in "codepage" all unused characters in
> "iocharset" (those to which no one of "codepage"'s characters is mapped) and
> then maps unmapped characters to those unused characters. This works
> perfectly. I used this approach in my first attempt which introduced koi8-r
> only and were rejected by you several months ago.

Again, this is not HFS-specific. Create a dynamic nls translation module 
and use this from HFS, this code does not belong in HFS.
I would accept a translation similiar to fat, anything else has to be done 
at the nls layer.

>  Instead of two arguments (unsigned char *table, struct nls_table *nls) ? May
> be struct hfs_sb_info *sbi instead in order to avoid additional HFS_SB()
> macro?

No, superblock info is passed as "struct superblock *".

bye, Roman