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
Attachment:
signature.asc
Description: This is a digitally signed message part.