LKML Archive on
help / color / mirror / Atom feed
From: "Alexander E. Patrakov" <>
To: OGAWA Hirofumi <>
Cc: LKML <>,
	Andrew Morton <>,, Kay Sievers <>
Subject: Re: [PATCH] Sanitize filesystem NLS handling
Date: Mon, 19 Mar 2007 07:58:49 +0500	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

OGAWA Hirofumi wrote:
> "Alexander E. Patrakov" <> writes:
>> 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.

>> 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.

>> 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

  reply	other threads:[~2007-03-19  2:58 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-03-18 16:55 Alexander E. Patrakov
2007-03-18 22:01 ` OGAWA Hirofumi
2007-03-19  2:58   ` Alexander E. Patrakov [this message]
2007-03-19  3:46     ` OGAWA Hirofumi
2007-03-19  4:38       ` Alexander E. Patrakov
2007-03-19  5:38         ` OGAWA Hirofumi
2007-03-19  5:49           ` Alexander E. Patrakov
2007-03-19 14:25             ` OGAWA Hirofumi
2007-03-19 15:04               ` Alexander E. Patrakov
2007-03-19 17:26                 ` OGAWA Hirofumi
2007-03-20  6:25                   ` Alexander E. Patrakov
2007-03-21 16:50                     ` OGAWA Hirofumi
2007-03-19 15:10               ` Alexander E. Patrakov
2007-03-19 17:36                 ` OGAWA Hirofumi
2007-03-19  6:38     ` yes --help (was: [PATCH] Sanitize filesystem NLS handling) Bernd Eckenfels
2007-03-19  8:14       ` Alexander E. Patrakov
2007-03-22 12:59 ` [PATCH] Sanitize filesystem NLS handling Roman Zippel
2007-03-22 13:22   ` Alexander E. Patrakov
2007-03-22 13:49     ` Roman Zippel
2007-03-22 13:59       ` Alexander E. Patrakov
2007-03-22 15:45         ` Roman Zippel
2007-03-22 14:58       ` Alexander E. Patrakov
2007-03-22 16:07 ` Alexander E. Patrakov

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \ \ \ \
    --subject='Re: [PATCH] Sanitize filesystem NLS handling' \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).