Re: [PATCH] xfstests: exclude hfs/hfsplus from generic/339 run

[Viacheslav Dubeyko <slava@dubeyko.com>]

On Thu, 2026-09-10 at 09:49 -0400, Theodore Tso wrote:
> On Thu, Sep 10, 2026 at 02:57:12AM -0500, Christoph Hellwig wrote:
> > On Wed, Sep 09, 2026 at 05:04:50PM -0700, Viacheslav Dubeyko wrote:
> > > The dirhash_collide generates filenames from arbitrary random
> > > bytes (only '.' and '/' are filtered out), which are not valid
> > > UTF-8 in general. Catalog names on both classic HFS and HFS+ are
> > > Unicode. Feeding random bytes causes fsck to report "Illegal
> > > name"
> > > or catalog corruption that has nothing to do with directory
> > > hash-collision handling, which is what this test is actually
> > > meant
> > > to exercise.
> 
> I'm curious --- does HFS/HFS+ reject unofficial Unicode characters
> such as those used by Klingon?  (Klingon is an invented/artificial
> language, so it's considered out of scope by Unicode; so Star Trek
> enthusiasts are camping on an unofficial block of the Unicode code
> set.)

I need to double check which particular Unicode characters fsck.hfsplus
treats as invalid one.

> 
> Invalid Unicode characters could also happen because newer versions
> of Unicode have added new emoji's, which might be added as support in
> the mobile handset userspace, but since we aren't regularly updating
> the Unicode tables, they might still be considered invalid if you
> enable strict mode in ext4/f2fs.
> 
> > If user file name creation manage to trigger fsck complaints, you
> > need
> > to righten the input checks in the file systems first to fix this.
> > 
> > We can then find a programmatic way to deal with these rejects in
> > xfstests, as ext4/f2fs in case insensiive mode probably have the
> > same
> > issue.
> 
> Well, strict mode isn't enabled by default, since users might want to
> use Klingon or emoji's with a skin color that matches their own.  And
> no one has been invested enough to continuously update our Unicode
> tables, and add support in the userspace tooling for upgrading the
> Unicode version in the file system superblock (which would then break
> compatibility with older kernels --- for example, if they downgrade
> to
> an older version of Android, etc.)
> 
> Isn't Unicode **fun**?  :-)

Could we have any generic way to detect that file system could not
support some Unicode characters?

Thanks,
Slava.