From mboxrd@z Thu Jan 1 00:00:00 1970 From: Pavel Fedin Subject: Re: [PATCH] Full NLS support for HFS (classic) filesystem Date: Tue, 31 May 2005 15:35:17 -0400 Message-ID: <429CBC75.2030605@rambler.ru> References: <429B1E35.2040905@rambler.ru> <429C68A0.20003@rambler.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: linux-fsdevel@vger.kernel.org Return-path: Received: from mxb.rambler.ru ([81.19.66.30]:45318 "EHLO mxb.rambler.ru") by vger.kernel.org with ESMTP id S261872AbVEaLeT (ORCPT ); Tue, 31 May 2005 07:34:19 -0400 To: Roman Zippel In-Reply-To: Sender: linux-fsdevel-owner@vger.kernel.org List-Id: linux-fsdevel.vger.kernel.org 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