lkml.org 
[lkml]   [2007]   [Mar]   [18]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH] Sanitize filesystem NLS handling
OGAWA Hirofumi wrote:
> "Alexander E. Patrakov" <patrakov@ums.usu.ru> writes:
>
>> * Removes CONFIG_FAT_DEFAULT_IOCHARSET, now CONFIG_NLS_DEFAULT is used
>> for this purpose. This is because the correct setting of both must match
>> the user's locale
>
> The some filesystems want to use utf-8, and others don't want to use
> utf-8, no? And is it also true about some devices using vfat?

Sorry, I can't parse this. Linux programs see filenames in the charset
specified by the "iocharset" mount option or this default. If some filenames
are in UTF-8 and some aren't, the "ls" command cannot show them all
correctly on a properly configured (aka: correctly displays the output of
"yes --help") terminal (because it assumes that all filenames are in the
same charset as indicated by the output of "locale charmap"). IMHO, this is
insane enough, and it makes sense to disable this by default.

>> * Merges the two CONFIG_SMB_NLS_REMOTE and CONFIG_FAT_DEFAULT_CODEPAGE
>> options into one, named CONFIG_CODEPAGE_DEFAULT. This is because the
>> correct setting of both must match the code page used by MS-DOS in the
>> user's country. For the same reason, CONFIG_SMB_NLS_DEFAULT is removed
>> (the only sane choice is "y")
>
> No. Unfortunately the real is not simple like it in some case.

More details please. Are you saying that for Japanese people the codepage
for FAT and SMB filesystems is not the same? How do Microsoft products work
then? What do they send over the wire?

>> * Makes the FAT filesystem accept both the old-style "codepage=866"
>> mount option (which is inconsistent with other filesystems requiring a
>> codepage option) and the new-style "codepage=cp866" option. This is
>> necessary because CONFIG_CODEPAGE_DEFAULT must work for all filesystems
>> that use it
>
> You allow to set any nls to codepage? If so, it is not good.

I did this because it involved less changes. Only FAT treats codepage as a
number. All other filesystems already allow arbitrary NLS as a codepage
mount parameter.

>> * Downgrades the UTF-8 FAT warning to a note, because, while using the
>> utf8 iocharset produces a case-sensitive FAT filesystem, other
>> iocharsets simply produce wrong characters, which is much worse
>
> No, utf-8 makes completely wrong entry. It's more wrong than other nls.

For any non-UTF-8 based locales, the other NLS is correct and utf8 indeed
would produce completely wrong characters. But for UTF-8 based locales, utf8
is the only correct iocharset.

And the downgraded warning is not for those who mis-use the utf8 iocharset
in non-UTF-8 locales, they need a completely different wording: "your
iocharset doesn't match the locale settings, non-ASCII characters will be
completely wrong in filenames". Unfortunately, this condition is impossible
to detect from within the kernel.

>> * Makes CONFIG_NLS_DEFAULT and CONFIG_CODEPAGE_DEFAULT adjustable at
>> runtime via the following mechanisms:
>
> The configurable sounds sane, and it may help some case. But, it should
> not be system global. At least, I think the default would be per-filesystem,
> otherwise some configs seems to be needed for other filesystem after all.

OK, now I see that your primary objection is to merging options, and
disagree (incorrect locale setup on your side is suspected). For meaningful
discussion, I want to see the following:

1) Output of "locale -a"
2) Output of "yes --help" from the same terminal
3) The correct iocharset and codepage for mounting FAT filesystems on USB
flash drives that are known readable under Windows (here "correct" = "ls in
this terminal shows filenames correctly").
4) The same for SMB filesystems.

--
Alexander E. Patrakov
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2007-03-19 04:01    [W:0.098 / U:1.380 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site