|
hfsplus_decompose_table (Apple Technote #1150) decomposes each source
character entirely on its own. It never reorders the result, and it
predates a handful of later corrections to the decomposition standard.
Two concrete consequences, both of which macOS's own fsck_hfs treats as
"Illegal name" (CatalogCheck.c: CheckCatalogName(), FixDecomps()):
- When combining marks contributed by two different source characters
end up adjacent, this driver stores them in input order rather than
ascending Unicode combining-class order.
- A small, fixed set of characters either aren't decomposed at all,
or are decomposed into a sequence macOS corrected back in
Mac OS X 10.2 ("Jaguar").
This is reliably reproducible: xfstests generic/339 exercises dirhash
collisions by creating many files with randomized Unicode names, and
the resulting HFS+ volume fails _check_generic_filesystem afterward
with a long run of "Illegal name" reports from fsck.hfsplus.
Fix hfsplus_asc2uni() to store names the way current macOS does, using
the Unicode tables:
- hfsplus_canonical_reorder() applies the Unicode Canonical Ordering
Algorithm: each maximal run of nonzero-combining-class code units is
stable-sorted into ascending class order.
- decompose_unichar() falls back to hfsplus_legacy_decompose() for the
characters missing from Apple Technote #1150's table.
- hfsplus_fixup_legacy_sequences() substitutes any of fsck_hfs's known
bad sequences with their corrected form.
hfsplus_decompose_str() ties these together and is now shared by
hfsplus_asc2uni(), hfsplus_hash_dentry() and hfsplus_compare_dentry(),
so hashing and comparison always agree with what actually gets stored -
otherwise two byte-for-byte different but canonically-equivalent
spellings of a name could hash differently or fail to compare equal
against the catalog entry a create() of either would produce.
cc: John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de>
cc: Yangtao Li <frank.li@vivo.com>
cc: linux-fsdevel@vger.kernel.org
Signed-off-by: Viacheslav Dubeyko <slava@dubeyko.com>
Link: https://lore.kernel.org/r/20260919001607.2777138-3-slava@dubeyko.com
Signed-off-by: Viacheslav Dubeyko <slava@dubeyko.com>
|
|
macOS's own fsck_hfs rejects a catalog name as "Illegal name" in two
cases this driver's decomposition tables don't currently account for:
- a decomposed name whose combining marks aren't in Unicode canonical
combining-class order (fsck_hfs's FixDecomps(), CatalogCheck.c);
- a small, fixed set of characters whose canonical decomposition either
wasn't yet defined, or was later corrected, since the driver's
existing hfsplus_decompose_table (Apple Technote #1150) predates
those corrections, which macOS has applied since Mac OS X 10.2
("Jaguar", 2002).
This is purely a data patch and adds no new behavior on its own:
- hfsplus_ccc_table: canonical combining class per BMP code point,
generated from the Unicode Character Database version 12.1.0
(https://www.unicode.org/Public/12.1.0/ucd/extracted/
DerivedCombiningClass.txt), the same UCD version fs/unicode's
README.utf8data documents.
- hfsplus_legacy_decomp_table and hfsplus_legacy_seq_fixups: the
corrected decompositions and sequence replacements fsck_hfs itself
requires, decoded from hfsprogs 540.1's
fsck_hfs.tproj/dfalib/DecompData.h (upstream: Apple's diskdev_cmds,
https://opensource.apple.com/source/diskdev_cmds/).
The three new struct types and the extern declarations for all of
tables.c's tables (existing and new) move into a new fs/hfsplus/
unicode.h, replacing the ad hoc externs that used to live in
hfsplus_fs.h.
cc: John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de>
cc: Yangtao Li <frank.li@vivo.com>
cc: linux-fsdevel@vger.kernel.org
Signed-off-by: Viacheslav Dubeyko <slava@dubeyko.com>
Link: https://lore.kernel.org/r/20260919001607.2777138-2-slava@dubeyko.com
Signed-off-by: Viacheslav Dubeyko <slava@dubeyko.com>
|
