Bug#500540: Considerations.

[Heinrich Langos]

Hi Raúl,

I'm sorry I didn't respond to your comment on this bug as I am not subscribed 
to it.

On Saturday 08 November 2008 19:01:23 Raúl Sánchez Siles wrote:
>  Some time ago, no sooner than Etch was released,   
> CONFIG_FAT_DEFAULT_CODEPAGE  
> was 437(cp437) and CONFIG_FAT_DEFAULT_IOCHARSET was iso8859-1 (latin1). But 
> after http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=417324 it was changed 
> to current 437 and utf8, respectively.
> 
>   Things being like this, using utf8 as long file name encoding, results in 
> case sensitive file names. I find this indeed a drawback, but using uft8 has 
> the advantage of support for non-ascii chars.  [Or at least supporting it 
> correctly]

As far as I can tell your analysis is correct. But (and this is a big "but") 
you seem 
to have ignored the utf8 flag. The effect of using a non-utf8 iocharset and the 
utf8 
flag is that long filenames will be encoded in utf8 and the iocharset will only 
be used
for case comparison. IMHO this is the "real solution" that you are looking for, 
but
there is (or was?) a problem with making it the default. (See Message#48 for 
details).

Cheers,
-henrik






--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#500540: Considerations.

[Raúl Sánchez Siles]

  Hello All:

  I've been investigating this issue with the help of Sune and Modestas, and 
I've also read some documentation from the internet.

  Things are like this:

  When you mount a vfat FS, there are 2 parameters which define the charset 
used to do translation to FS. This parameters are: codepage and iocharset. 
There's a third parameter, utf8 which helps handling this conversion when 
source or destination is utf8 from as set in your locale.

  These 2 parameters take its default value from GNU/Linux kernel 
configuration, namely: CONFIG_FAT_DEFAULT_CODEPAGE and 
CONFIG_FAT_DEFAULT_IOCHARSET

  codepage is used to do translation from your locale to FS charset when the 
filename is considered short in that FS, this is, it fits the 8.3 pattern, 
where 8 is the filename length and 3 is the extension length. This behaviour 
is defined like this because on fat and vfat systems the long filenames uses 
unicode to store its filename.

  Some time ago, no sooner than Etch was released, CONFIG_FAT_DEFAULT_CODEPAGE 
was 437(cp437) and CONFIG_FAT_DEFAULT_IOCHARSET was iso8859-1 (latin1). But 
after http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=417324 it was changed 
to current 437 and utf8, respectively.

  Things being like this, using utf8 as long file name encoding, results in 
case sensitive file names. I find this indeed a drawback, but using uft8 has 
the advantage of support for non-ascii chars.  [Or at least supporting it 
correctly]

  This is all I can say so far. I'll go on thinking about this, in case I find 
a real solution.

  Regards,


-- 
 Raúl Sánchez Siles
->Proud Debian user<-
Linux registered user #416098


signature.asc
Description: This is a digitally signed message part.