From: "Maciej S. Szmigiero" <mail@maciej.szmigiero.name>
To: Josh Boyer <jwboyer@fedoraproject.org>,
Geert Uytterhoeven <geert@linux-m68k.org>
Cc: OGAWA Hirofumi <hirofumi@mail.parknet.co.jp>,
Jonathan Corbet <corbet@lwn.net>,
"linux-doc@vger.kernel.org" <linux-doc@vger.kernel.org>,
linux-kernel <linux-kernel@vger.kernel.org>
Subject: Re: [PATCHv2] fat: add config option to set UTF-8 mount option by default
Date: Wed, 23 Mar 2016 17:41:12 +0100 [thread overview]
Message-ID: <56F2C728.50309@maciej.szmigiero.name> (raw)
In-Reply-To: <CA+5PVA6Fu_K1rXz9pP-WfbnYu-bu4v3hEhcu+LeMcPeYDMKRwg@mail.gmail.com>
On 23.03.2016 13:57, Josh Boyer wrote:
> On Wed, Mar 23, 2016 at 8:27 AM, Geert Uytterhoeven
> <geert@linux-m68k.org> wrote:
>> On Wed, Mar 23, 2016 at 12:28 PM, Josh Boyer <jwboyer@fedoraproject.org> wrote:
>>> On Wed, Mar 23, 2016 at 4:17 AM, Geert Uytterhoeven
>>> <geert@linux-m68k.org> wrote:
>>>> On Tue, Mar 8, 2016 at 2:53 PM, Maciej S. Szmigiero
>>>> <mail@maciej.szmigiero.name> wrote:
>>>>> FAT has long supported its own default file name encoding
>>>>> config setting, separate from CONFIG_NLS_DEFAULT.
>>>>>
>>>>> However, if UTF-8 encoded file names are desired FAT
>>>>> character set should not be set to utf8 since this would
>>>>> make file names case sensitive even if case insensitive
>>>>> matching is requested.
>>>>> Instead, "utf8" mount options should be provided to enable
>>>>> UTF-8 file names in FAT file system.
>>>>>
>>>>> Unfortunately, there was no possibility to set the default
>>>>> value of this option so on UTF-8 system "utf8" mount option
>>>>> had to be added manually to most FAT mounts.
>>>>>
>>>>> This patch adds config option to set such default value.
>>>>>
>>>>> Signed-off-by: Maciej S. Szmigiero <mail@maciej.szmigiero.name>
>>>>
>>>>> --- a/fs/fat/Kconfig
>>>>> +++ b/fs/fat/Kconfig
>>>>> @@ -93,8 +93,24 @@ config FAT_DEFAULT_IOCHARSET
>>>>> that most of your FAT filesystems use, and can be overridden
>>>>> with the "iocharset" mount option for FAT filesystems.
>>>>> Note that "utf8" is not recommended for FAT filesystems.
>>>>> - If unsure, you shouldn't set "utf8" here.
>>>>> + If unsure, you shouldn't set "utf8" here - select the next option
>>>>> + instead if you would like to use UTF-8 encoded file names by default.
>>>>> See <file:Documentation/filesystems/vfat.txt> for more information.
>>>>>
>>>>> Enable any character sets you need in File Systems/Native Language
>>>>> Support.
>>>>> +
>>>>> +config FAT_DEFAULT_UTF8
>>>>> + bool "Enable FAT UTF-8 option by default"
>>>>> + depends on VFAT_FS
>>>>> + default n
>>>>> + help
>>>>> + Set this if you would like to have "utf8" mount option set
>>>>> + by default when mounting FAT filesystems.
>>>>> +
>>>>> + Even if you say Y here can always disable UTF-8 for
>>>>> + particular mount by adding "utf8=0" to mount options.
>>>>> +
>>>>> + Say Y if you use UTF-8 encoding for file names, N otherwise.
>>>>> +
>>>>> + See <file:Documentation/filesystems/vfat.txt> for more information.
>>>>
>>>> What's the recommended value of CONFIG_FAT_DEFAULT_UTF8 for
>>>> a (distro) defconfig?
>>>
>>> Yes, I'm curious about this as well. My initial assumption is to
>>> leave it off, given that if you turn it on when it wasn't previously
>>> it will change the behavior. I would also assume that is why it is
>>> marked as default n.
>>
>> "default n" is superfluous, as all options default to "n" in the absence
>> of a default specifier.
>
> Yes, I know that. I meant that I assumed the patch author knows that
> too, and included it anyway as a helpful indicator that it shouldn't
> be turned on in most cases. At any rate, your question still stands
> and it would be nice to get an answer.
The default is 'n' here for compatibility with older .configs,
and to be consistent with the main FS NLS option (CONFIG_NLS_DEFAULT)
since it also defaults to non-UTF-8 encoding.
If file names are UTF-8 encoded then if FAT filesystems were always
mounted with utf8 mount option, or with CONFIG_FAT_DEFAULT_IOCHARSET or
"iocharset" mount option set to "utf8" (not recommended,
but I've seen for example Knoppix doing it) then with this options set
there is effectively no change in functionality.
If file names are UTF-8 encoded but none of conditions described in
the previous paragraph were true then UTF-8 file names were reinterpreted
as CONFIG_FAT_DEFAULT_IOCHARSET (by default iso8859-1) then converted
into UTF-16 for storage.
While this usually worked it weren't correct: file names containing
characters outside ASCII had them replaced with some garbage when
accessing such FS with UTF-8 correctly enabled (for example with this
option set) or on Windows.
However, if such conditions (UTF-8 file names but non-UTF-8 FAT mount
options) were present for a long time then it has to be taken into
consideration that there are likely at least a few file systems with
file names encoded in such way and it would be good not to change it
suddenly when people update their kernels.
> josh
Maciej
prev parent reply other threads:[~2016-03-23 16:41 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-03-08 13:53 Maciej S. Szmigiero
2016-03-08 18:08 ` OGAWA Hirofumi
2016-03-23 8:17 ` Geert Uytterhoeven
2016-03-23 11:28 ` Josh Boyer
2016-03-23 12:27 ` Geert Uytterhoeven
2016-03-23 12:57 ` Josh Boyer
2016-03-23 16:41 ` Maciej S. Szmigiero [this message]
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:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=56F2C728.50309@maciej.szmigiero.name \
--to=mail@maciej.szmigiero.name \
--cc=corbet@lwn.net \
--cc=geert@linux-m68k.org \
--cc=hirofumi@mail.parknet.co.jp \
--cc=jwboyer@fedoraproject.org \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®