All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Pali Rohár" <pali@kernel.org>
To: OGAWA Hirofumi <hirofumi@mail.parknet.co.jp>
Cc: linux-fsdevel@vger.kernel.org,
	linux-ntfs-dev@lists.sourceforge.net, linux-cifs@vger.kernel.org,
	jfs-discussion@lists.sourceforge.net,
	linux-kernel@vger.kernel.org,
	Alexander Viro <viro@zeniv.linux.org.uk>, Jan Kara <jack@suse.cz>,
	"Theodore Y . Ts'o" <tytso@mit.edu>,
	Anton Altaparmakov <anton@tuxera.com>,
	Luis de Bethencourt <luisbg@kernel.org>,
	Salah Triki <salah.triki@gmail.com>,
	Steve French <sfrench@samba.org>, Paulo Alcantara <pc@cjr.nz>,
	Ronnie Sahlberg <lsahlber@redhat.com>,
	Shyam Prasad N <sprasad@microsoft.com>,
	Tom Talpey <tom@talpey.com>, Dave Kleikamp <shaggy@kernel.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	Pavel Machek <pavel@ucw.cz>,
	Christoph Hellwig <hch@infradead.org>,
	Kari Argillander <kari.argillander@gmail.com>,
	Viacheslav Dubeyko <slava@dubeyko.com>
Subject: Re: [RFC PATCH v2 01/18] fat: Fix iocharset=utf8 mount option
Date: Sat, 4 Feb 2023 11:57:03 +0100	[thread overview]
Message-ID: <20230204105703.pnc6vcy4hvmvvm3b@pali> (raw)
In-Reply-To: <874jsyvje6.fsf@mail.parknet.co.jp>

On Tuesday 10 January 2023 18:17:05 OGAWA Hirofumi wrote:
> Pali Rohár <pali@kernel.org> writes:
> 
> > Currently iocharset=utf8 mount option is broken and error is printed to
> > dmesg when it is used. To use UTF-8 as iocharset, it is required to use
> > utf8=1 mount option.
> >
> > Fix iocharset=utf8 mount option to use be equivalent to the utf8=1 mount
> > option and remove printing error from dmesg.
> 
> [...]
> 
> > -
> > -	There is also an option of doing UTF-8 translations
> > -	with the utf8 option.
> > -
> > -.. note:: ``iocharset=utf8`` is not recommended. If unsure, you should consider
> > -	  the utf8 option instead.
> > +	**utf8** is supported too and recommended to use.
> >  
> >  **utf8=<bool>**
> > -	UTF-8 is the filesystem safe version of Unicode that
> > -	is used by the console. It can be enabled or disabled
> > -	for the filesystem with this option.
> > -	If 'uni_xlate' gets set, UTF-8 gets disabled.
> > -	By default, FAT_DEFAULT_UTF8 setting is used.
> > +	Alias for ``iocharset=utf8`` mount option.
> >  
> >  **uni_xlate=<bool>**
> >  	Translate unhandled Unicode characters to special
> > diff --git a/fs/fat/Kconfig b/fs/fat/Kconfig
> > index 238cc55f84c4..e98aaa3bb55b 100644
> > --- a/fs/fat/Kconfig
> > +++ b/fs/fat/Kconfig
> > @@ -93,29 +93,12 @@ config FAT_DEFAULT_IOCHARSET
> >  	  like FAT to use. It should probably match the character set
> >  	  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 - select the next option
> > -	  instead if you would like to use UTF-8 encoded file names by default.
> > +	  "utf8" is supported too and recommended to use.
> 
> This patch fixes the issue of utf-8 partially only. I think we can't
> still recommend only partially working one.

With this patch FAT_DEFAULT_IOCHARSET=utf8 is same what was
FAT_DEFAULT_UTF8=y without this patch. And option FAT_DEFAULT_UTF8 was
recommended in description before "select the next option instead if you
would like to use UTF-8 encoded file names by default."

> [...]
> 
> > -	opts->utf8 = IS_ENABLED(CONFIG_FAT_DEFAULT_UTF8) && is_vfat;
> > -
> >  	if (!options)
> >  		goto out;
> >  
> > @@ -1318,10 +1316,14 @@ static int parse_options(struct super_block *sb, char *options, int is_vfat,
> >  					| VFAT_SFN_CREATE_WIN95;
> >  			break;
> >  		case Opt_utf8_no:		/* 0 or no or false */
> > -			opts->utf8 = 0;
> > +			fat_reset_iocharset(opts);
> 
> This changes the behavior of "iocharset=iso8859-1,utf8=no" for
> example. Do we need this user visible change here?

Ok, I agree, we do not want to change iocharset when
"iocharset=iso8859-1,utf8=no" was specified. It should stay on
iso8859-1.

> >  			break;
> >  		case Opt_utf8_yes:		/* empty or 1 or yes or true */
> > -			opts->utf8 = 1;
> > +			fat_reset_iocharset(opts);
> > +			iocharset = kstrdup("utf8", GFP_KERNEL);
> > +			if (!iocharset)
> > +				return -ENOMEM;
> > +			opts->iocharset = iocharset;
> >  			break;
> >  		case Opt_uni_xl_no:		/* 0 or no or false */
> >  			opts->unicode_xlate = 0;
> > @@ -1359,18 +1361,11 @@ static int parse_options(struct super_block *sb, char *options, int is_vfat,
> >  	}
> >  
> >  out:
> > -	/* UTF-8 doesn't provide FAT semantics */
> > -	if (!strcmp(opts->iocharset, "utf8")) {
> > -		fat_msg(sb, KERN_WARNING, "utf8 is not a recommended IO charset"
> > -		       " for FAT filesystems, filesystem will be "
> > -		       "case sensitive!");
> > -	}
> > +	opts->utf8 = !strcmp(opts->iocharset, "utf8") && is_vfat;
> 
> Still broken, so I think we still need the warning here (would be
> tweaked warning).

There was no warning before for utf8=1. And with this patch
iocharset=utf8 should have same behavior as what was utf8=1 before this
patch.

So if we should show some warning for utf8=1 then it is somehow not
related to this patch and it should be done separately, possible also to
the current codebase and before this patch.

> >  	/* If user doesn't specify allow_utime, it's initialized from dmask. */
> >  	if (opts->allow_utime == (unsigned short)-1)
> >  		opts->allow_utime = ~opts->fs_dmask & (S_IWGRP | S_IWOTH);
> > -	if (opts->unicode_xlate)
> > -		opts->utf8 = 0;
> 
> unicode_xlate option is exclusive with utf8, need to adjust
> somewhere. (with this patch, unicode_xlate and utf8 will shows by
> show_options())

Ok, seems that there is more work to handle unicode_xlate option
correctly.

> > +	else if (utf8)
> > +		return fat_utf8_strnicmp(name->name, str, alen);
> > +	else
> > +		return nls_strnicmp(t, name->name, str, alen);
> >  }
> 
> Not strong opinion though, maybe we better to consolidate this to a
> (inline) function? (FWIW, it may be better to refactor to provide some
> filename functions to hide the detail of handling nls/utf8)

This looks like an another cleanup / improvement which can be done. I'm
not sure if it is a good idea to put into this patch series (it is
already big).

  reply	other threads:[~2023-02-04 10:57 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-12-26 14:21 [RFC PATCH v2 00/18] fs: Remove usage of broken nls_utf8 and drop it Pali Rohár
2022-12-26 14:21 ` [RFC PATCH v2 01/18] fat: Fix iocharset=utf8 mount option Pali Rohár
2023-01-10  9:17   ` OGAWA Hirofumi
2023-02-04 10:57     ` Pali Rohár [this message]
2023-02-08 10:10       ` OGAWA Hirofumi
2022-12-26 14:21 ` [RFC PATCH v2 02/18] hfsplus: Add iocharset= mount option as alias for nls= Pali Rohár
2022-12-26 14:21 ` [RFC PATCH v2 03/18] ntfs: Undeprecate iocharset= mount option Pali Rohár
2023-01-01 19:02   ` Kari Argillander
2023-01-01 19:06     ` Pali Rohár
2023-01-01 23:02       ` Pali Rohár
2022-12-26 14:21 ` [RFC PATCH v2 04/18] ntfs: Fix error processing when load_nls() fails Pali Rohár
2022-12-26 14:21 ` [RFC PATCH v2 05/18] befs: Fix printing iocharset= mount option Pali Rohár
2022-12-26 14:21 ` [RFC PATCH v2 06/18] befs: Rename enum value Opt_charset to Opt_iocharset to match " Pali Rohár
2022-12-26 14:21 ` [RFC PATCH v2 07/18] befs: Fix error processing when load_nls() fails Pali Rohár
2022-12-26 14:21 ` [RFC PATCH v2 08/18] befs: Allow to use native UTF-8 mode Pali Rohár
2022-12-26 14:21 ` [RFC PATCH v2 09/18] hfs: Explicitly set hsb->nls_disk when hsb->nls_io is set Pali Rohár
2022-12-26 14:21 ` [RFC PATCH v2 10/18] hfs: Do not use broken utf8 NLS table for iocharset=utf8 mount option Pali Rohár
2022-12-26 14:21 ` [RFC PATCH v2 11/18] hfsplus: " Pali Rohár
2022-12-26 14:21 ` [RFC PATCH v2 12/18] jfs: Remove custom iso8859-1 implementation Pali Rohár
2022-12-26 14:21 ` [RFC PATCH v2 13/18] jfs: Fix buffer overflow in jfs_strfromUCS_le() function Pali Rohár
2022-12-26 14:21 ` [RFC PATCH v2 14/18] jfs: Do not use broken utf8 NLS table for iocharset=utf8 mount option Pali Rohár
2022-12-26 14:21 ` [RFC PATCH v2 15/18] ntfs: " Pali Rohár
2022-12-26 14:21 ` [RFC PATCH v2 16/18] cifs: " Pali Rohár
2022-12-26 14:21 ` [RFC PATCH v2 17/18] cifs: Remove usage of load_nls_default() calls Pali Rohár
2022-12-26 14:21 ` [RFC PATCH v2 18/18] nls: Drop broken nls_utf8 module Pali Rohár

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=20230204105703.pnc6vcy4hvmvvm3b@pali \
    --to=pali@kernel.org \
    --cc=akpm@linux-foundation.org \
    --cc=anton@tuxera.com \
    --cc=hch@infradead.org \
    --cc=hirofumi@mail.parknet.co.jp \
    --cc=jack@suse.cz \
    --cc=jfs-discussion@lists.sourceforge.net \
    --cc=kari.argillander@gmail.com \
    --cc=linux-cifs@vger.kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-ntfs-dev@lists.sourceforge.net \
    --cc=lsahlber@redhat.com \
    --cc=luisbg@kernel.org \
    --cc=pavel@ucw.cz \
    --cc=pc@cjr.nz \
    --cc=salah.triki@gmail.com \
    --cc=sfrench@samba.org \
    --cc=shaggy@kernel.org \
    --cc=slava@dubeyko.com \
    --cc=sprasad@microsoft.com \
    --cc=tom@talpey.com \
    --cc=tytso@mit.edu \
    --cc=viro@zeniv.linux.org.uk \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.