linux-kernel - RE: [PATCH v5 08/10] fs/ntfs3: Add Kconfig, Makefile and doc

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Fri, 25 Sep 2020 16:30:19 +0000
From:   Konstantin Komarov <almaz.alexandrovich@...agon-software.com>
To:     Pali Rohár <pali@...nel.org>
CC:     "linux-fsdevel@...r.kernel.org" <linux-fsdevel@...r.kernel.org>,
        "viro@...iv.linux.org.uk" <viro@...iv.linux.org.uk>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "dsterba@...e.cz" <dsterba@...e.cz>,
        "aaptel@...e.com" <aaptel@...e.com>,
        "willy@...radead.org" <willy@...radead.org>,
        "rdunlap@...radead.org" <rdunlap@...radead.org>,
        "joe@...ches.com" <joe@...ches.com>,
        "mark@...mstone.com" <mark@...mstone.com>,
        "nborisov@...e.com" <nborisov@...e.com>
Subject: RE: [PATCH v5 08/10] fs/ntfs3: Add Kconfig, Makefile and doc

From: Pali Rohár <pali@...nel.org>
Sent: Monday, September 21, 2020 4:27 PM
> 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.

Hi Pali! Thanks for the feedback. We do not consider the nls_alt option as the must have
one. But it is very nice "QOL-type" mount option, which may help some amount of
dual-booters/Windows users to avoid tricky fails with files originated on non-English
Windows systems. One of the cases where this one may be useful is the case of zipping
files with non-English names (e.g. Polish etc) under Windows and then unzipping the archive
under Linux. In this case unzip will likely to fail on those files, as archive stores filenames not
in utf. Windows have that "Language for non-Unicode programs" setting, which controls the
encoding used for the described (and similar) cases.
Overall, it's kinda niche mount option, but we suppose it's legit for Windows-originated filesystems.
What do you think on this, Pali?

Best regards!