--
FWIW, I had what appears to be the same problem with 2.6.9 kernel, and it
worked fine on
2.6.6. So likely something changed either in 2.6.8 -> 2.6.9 or in
2.6.7 -> 2.6.8
Examining the 2.6.8 changelog finds this:
<[EMAIL PROTECTED]>
[PATCH] FAT: don't use "utf8" charset and NLS_DEFAULT
Recently, some distributors have set "utf8" to NLS_DEFAULT, therefore,
FAT uses the "iocharset=utf8" as default. But, since "iocharset=utf8"
doesn't provide the function (lower <-> upper conversion) which FAT
needs, so FAT can't provide suitable behavior.
This patch does:
- doesn't recognize "utf8" as "iocharset"
- doesn't use NLS_DEFAULT as default "iocharset"
- instead of NLS_DEFAULT, adds FAT_DEFAULT_CODEPAGE and
FAT_DEFAULT_IOCHARSET
NOTE: the following looks like buggy, so it's not recommended
"codepage=437,iocharset=iso8859-1,utf8"
however, some utf8 file name can handle. (in this case, it uses the
table of iso8859-1 for lower <-> upper conversion)
Which while it covers an undefined behaviour, it does so with much
ugliness, and at the cost of usability, especially since it loked like
the problem was with codepage 437, even though it loaded successfully.
--
Aaron Denney
-><-
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
