From: David Timber <dxdt@dev.snart.me>
To: Zhan Xusheng <zhanxusheng1024@gmail.com>, linkinjeon@kernel.org
Cc: sj1557.seo@samsung.com, yuezhang.mo@sony.com,
exfat@lists.linux.dev, anmuxixixi@gmail.com,
chizhiling@kylinos.cn, linux-kernel@vger.kernel.org,
zhanxusheng@xiaomi.com
Subject: Re: [PATCH] exfat: doc: add documentation
Date: Tue, 1 Sep 2026 07:18:41 +0000 [thread overview]
Message-ID: <154d417a-65d7-42ba-84d1-ea7834e11c8d@dev.snart.me> (raw)
In-Reply-To: <20260831144929.1597433-1-zhanxusheng@xiaomi.com>
On 8/31/26 14:49, Zhan Xusheng wrote:
> The option list and the defaults match fs/exfat/, including the allow_utime
> derivation and the time_offset range. Three things the table leaves out or
> implies.
>
> Most of the options cannot be changed on remount. exfat_reconfigure()
> fails with -EINVAL if iocharset, keep_last_dots, sys_tz, time_offset, uid,
> gid, fmask, dmask or allow_utime differ from the current values
> (super.c:789), leaving only errors, discard and zero_size_dir. Nothing is
> logged on that path, so "mount -o remount,uid=1000" returns a bare EINVAL.
> The reason sits in the code right above the test: the old values are cached
> in inodes and dentries.
>
> umask= sets both masks, and the options take effect in the order they are
> written. Opt_umask assigns fs_fmask and fs_dmask (super.c:289), so
> "-o umask=0022,dmask=0077" ends up with dmask 0077, while
> "-o dmask=0077,umask=0022" silently puts dmask back to 0022. The dmask=
> and fmask= entries also do not give their default, which is the same
> current umask that umask= defaults to.
>
> utf8 is ignored rather than an old spelling of iocharset=utf8. It shares a
> fallthrough with debug, namecase= and codepage= (super.c:331), so
> "mount -o utf8" selects nothing. exfat_show_options() prints
> iocharset=utf8 only when opts->utf8 is set (super.c:132), and nothing sets
> that but iocharset=utf8. Listing utf8 apart from the group described as
> "Deprecated and ignored" reads as if it still has an effect.
>
> Thanks,
> Zhan Xusheng
idk.. The proposed documentation says nothing about the remount option
as of yet. Reconfiguartion of the most of mount options FAT isn't
supported either, but the documentation doesn't really specifically
mention that fact because there's little to no actual use case other
than remounting ro or rw.
Other than the last paragraph, these are separate issues not really
pertaininig to the proposed documentation, if they're valid. I suggest
that you submit patches fixing the issues if you'd like to contribute.
The valid point on "utf8", though. Opt_utf8 is ignored. I think this is
actually a bug in the implementation rather than a factual error in the
doc. "Deprecated" shouldn't mean "it's a no-op". They're totally
different things. fs/fat still honors it, so I think fs/exfat should do
the same.
Davo
next prev parent reply other threads:[~2026-09-01 7:18 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-31 10:53 Namjae Jeon
2026-08-31 14:49 ` Zhan Xusheng
2026-09-01 6:46 ` Namjae Jeon
2026-09-01 7:18 ` David Timber [this message]
2026-09-01 6:24 ` David Timber
2026-09-01 6:48 ` Namjae Jeon
2026-09-01 7:27 ` David Timber
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=154d417a-65d7-42ba-84d1-ea7834e11c8d@dev.snart.me \
--to=dxdt@dev.snart.me \
--cc=anmuxixixi@gmail.com \
--cc=chizhiling@kylinos.cn \
--cc=exfat@lists.linux.dev \
--cc=linkinjeon@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=sj1557.seo@samsung.com \
--cc=yuezhang.mo@sony.com \
--cc=zhanxusheng1024@gmail.com \
--cc=zhanxusheng@xiaomi.com \
/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®