[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20200921132631.q6jfmbhqf6j6ay5t@pali>
Date: Mon, 21 Sep 2020 15:26:31 +0200
From: Pali Rohár <pali@...nel.org>
To: Konstantin Komarov <almaz.alexandrovich@...agon-software.com>
Cc: linux-fsdevel@...r.kernel.org, viro@...iv.linux.org.uk,
linux-kernel@...r.kernel.org, dsterba@...e.cz, aaptel@...e.com,
willy@...radead.org, rdunlap@...radead.org, joe@...ches.com,
mark@...mstone.com, nborisov@...e.com
Subject: Re: [PATCH v5 08/10] fs/ntfs3: Add Kconfig, Makefile and doc
On Friday 11 September 2020 17:10:16 Konstantin Komarov wrote:
> +Mount Options
> +=============
> +
> +The list below describes mount options supported by NTFS3 driver in addition to
> +generic ones.
> +
> +===============================================================================
> +
> +nls=name This option informs the driver how to interpret path
> + strings and translate them to Unicode and back. If
> + this option is not set, the default codepage will be
> + used (CONFIG_NLS_DEFAULT).
> + Examples:
> + 'nls=utf8'
> +
> +nls_alt=name This option extends "nls". It will be used to translate
> + path string to Unicode if primary nls failed.
> + Examples:
> + 'nls_alt=cp1251'
Hello! I'm looking at other filesystem drivers and no other with UNICODE
semantic (vfat, udf, isofs) has something like nls_alt option.
So do we really need it? And if yes, it should be added to all other
UNICODE filesystem drivers for consistency.
But I'm very sceptical if such thing is really needed. nls= option just
said how to convert UNICODE code points for userpace. This option is
passed by userspace (when mounting disk), so userspace already know what
it wanted. And it should really use this encoding for filenames (e.g.
utf8 or cp1251) which already told to kernel.
Powered by blists - more mailing lists