On Monday 09 August 2021 18:37:19 Matthew Wilcox wrote:

On Mon, Aug 09, 2021 at 10:31:55AM -0700, Viacheslav Dubeyko wrote:

quoted

quoted

On Aug 8, 2021, at 9:24 AM, Pali Rohár [off-list ref] wrote:

It does not make any sense to set hsb->nls_io (NLS iocharset used between
VFS and hfs driver) when hsb->nls_disk (NLS codepage used between hfs
driver and disk) is not set.

Reverse engineering driver code shown what is doing in this special case:

   When codepage was not defined but iocharset was then
   hfs driver copied 8bit character from disk directly to
   16bit unicode wchar_t type. Which means it did conversion
   from Latin1 (ISO-8859-1) to Unicode because first 256
   Unicode code points matches 8bit ISO-8859-1 codepage table.
   So when iocharset was specified and codepage not, then
   codepage used implicit value "iso8859-1".

So when hsb->nls_disk is not set and hsb->nls_io is then explicitly set
hsb->nls_disk to "iso8859-1".

Such setup is obviously incompatible with Mac OS systems as they do not
support iso8859-1 encoding for hfs. So print warning into dmesg about this
fact.

After this change hsb->nls_disk is always set, so remove code paths for
case when hsb->nls_disk was not set as they are not needed anymore.

Sounds reasonable. But it will be great to know that the change has been tested reasonably well.

I don't think it's reasonable to ask Pali to test every single filesystem.
That's something the maintainer should do, as you're more likely to have
the infrastructure already set up to do testing of your filesystem and
be aware of fun corner cases and use cases than someone who's working
across all filesystems.

This patch series is currently in RFC form, as stated in cover letter
mostly untested. So they are not in form for merging or detailed
reviewing. I just would like to know if this is the right direction with
filesystems and if I should continue with this my effort or not.
And I thought that sending RFC "incomplete" patches is better way than
just describing what to do and how...