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

[Pavel Fedin <sonic_amiga@rambler.ru>]

Roman Zippel wrote:

>>/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??? It's incomfortable for the user!

>> 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.

  Yes, it may find wrong file. But i mean here that HFS does not use 
string comparison at all for finding a file but some specific hashing (i 
tried to understand how it actually works and was unable to, too 
difficult). So it just will not find many files at all, even if names 
are translated correctly. As i say, i tried this, it completely failed.

>> 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.

  This (if you mean that not all characters can be translated) is really 
not HFS-specific. But the fact that all characters MUST be 
reverse-translatable is HFS-specific.
  Don't understand about dynamic NLS module. What code should it contain?

> I would accept a translation similiar to fat, anything else has to be done 
> at the nls layer.

  Translation similar to FAT is unusable. Even files with correctly 
translated names will be not found.
  File searching at the end relies on hfs_strcmp() function which 
produces correct results only if supplied strings are in Mac encoding.
  I thought for a while and decided that dynamically created reversible 
translation table is the best and the simplest approach.
  Well, probably it's possible to rewrite hfs_strcmp() to use some 
dynamically created table. But... Again, it will be dynamically created. 
   And it requires many time of additional research but the result will 
be nearly the same.

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

  Ok, it's not a problem.

  P.S. I think you know the HFS implementation better than me. Why don't 
you beleive me that there is no other solution?

-- 
  Kind regards, Pavel Fedin