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

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

Hi,

On Tue, 31 May 2005, Pavel Fedin wrote:

> > Because it's a user space problem, if you want to use different codepages
> > for different cd's tell it to mount. The kernel only provides the
> > functionality, giving the same functionality several different names is not
> > an option.
> 
>  How is it possible (except using different mount points)?
>  Besides, using different mount points is problematic with automounters, only
> first fstab entry is taken into account by them. Second point won't be mounted
> automatically by, for example, magicdev.

So fix your tools, really, you are complaining to the wrong guy.

> > If the names were translated correctly, HFS would have found them. You need
> > to give me an example, which should have worked, but failed.
> 
>  I can't produce exact russian string (don't remember), but it was about 50%
> of all russian names.

Without an example I can't reproduce, what you're trying to say here (at 
least the "HFS doesn't find the file, even though it's correctly 
translated" part). 

> > Create the tables in a nls module and you can do whatever you want in the
> > uni2char/char2uni functions.
> 
>  Huh...
>  The problem is: when using 8-bit iocharset and 8-bit codepage char2uni from
> codepage always gives the result but AFTER THIS uni2char to iocharset does NOT
> necessarily gives the result. There are characters in codepage which have no
> equivalents in iocharset. They will be lost, you suggest to turn them into
> '?'. But how to reverse this in order to supply to hfs_strcmp()?

So create two functions uni2char/char2uni, which provide perfect reverse 
mapping. Sorry, but I don't understand what your problem is here.
It seems you're making it more complex than it really is.

bye, Roman