Hello, all! After a long thnking i implemented full NLS support for
MacHFS filesystem. This is the patch for 2.6.11.1 kernel.
Add "iocharset" and "hfscodepage" mount options to fstab for it to work.
"hfscodepage" option is also introduced to iso9660 and udf
filesystems. They ignore it. Both options are also added to hfsplus
filesystem. It also ignores them. This is done in order to enable user
to put one line into fstab like:
/dev/cdrom /mnt/cdrom iso9660,udf,hfsplus,hfs
user,noauto,iocharset=koi8-r,hfscodepage=10007 0 0
This allows you to have one mount point for all CD formats at last.
Codepage option is called "hfscodepage", not "codepage" because in
future "codepage" option might be added to iso9660 filesystem in order
to enable translation of 8-bit names and in many countries ISO codepage
differs from HFS codepage.
cp10007 nls table is also added by this patch. This codepage is used
on russian macintoshes.
Some technical details on the implementation:
HFS filesystem by nature requires filenames in Mac encoding to be
supplied to file search algorythm, otherwise it will not work. So two
different algorythms are used depending on used iocharset:
a) if iocharset=utf8 - all characters are reverse-convertable in this
case. NLS table is loaded for the specified codepage and conversion is
done using it.
b) if iocharset is not utf8 - not every character can be
reverse-translated in this case. To override this two tables are
composed on the fly from two supplied NLS pages using a tricky
algorythm. A 256 byte table is created and filled with characters taken
from NLS->NLS conversion. Those characters from 256-byte destination set
which were used are marked. After this all remaining entries in the
table (characters which had no equivalent in the destination NLS table)
are filled with characters which remained unused. Then resulting table
is reversed in order to provide a second table for reverse translation.
This implementation is rather tricky and probably sometimes it can
fail (i hope it won't, at least i tested it with hfscodepage=10007) so i
left a simple possibility to disable conversion by simply removing
iocharset and hfscodepage from hfs mount options.
--
Kind regards, Pavel Fedin
Hi,
On Mon, 30 May 2005, Pavel Fedin wrote:
> Codepage option is called "hfscodepage", not "codepage" because in
> future "codepage" option might be added to iso9660 filesystem in order
> to enable translation of 8-bit names and in many countries ISO codepage
> differs from HFS codepage.
If the codepage differs, you simply use different arguments for that
option. Is there a _technical_ reason why "hfscodepage" and "codepage"
might behave differently? Otherwise I'd prefer to use the same name for
the option.
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).
(BTW please try to inline the patch otherwise it's rather difficult to
quote from it.)
> + if (hsb->nls)
> + {
Please fix the coding style.
> +extern void hfs_triv2mac(struct hfs_name *, struct qstr *, unsigned char *, struct nls_table *);
If you add a new argument, use "struct superblock *sb" as the first
argument.
bye, Roman