NetBSD Problem Report #55427

From www@netbsd.org  Sun Jun 28 00:21:11 2020
Return-Path: <www@netbsd.org>
Received: from mail.netbsd.org (mail.netbsd.org [199.233.217.200])
	(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
	(Client CN "mail.NetBSD.org", Issuer "mail.NetBSD.org CA" (not verified))
	by mollari.NetBSD.org (Postfix) with ESMTPS id 36CB31A9217
	for <gnats-bugs@gnats.NetBSD.org>; Sun, 28 Jun 2020 00:21:11 +0000 (UTC)
Message-Id: <20200628002110.422481A9228@mollari.NetBSD.org>
Date: Sun, 28 Jun 2020 00:21:10 +0000 (UTC)
From: ageng@alum.mit.edu
Reply-To: ageng@alum.mit.edu
To: gnats-bugs@NetBSD.org
Subject: libhfs cannot find some filenames containing non-ASCII chars
X-Send-Pr-Version: www-1.0

>Number:         55427
>Category:       kern
>Synopsis:       libhfs cannot find some filenames containing non-ASCII chars
>Confidential:   no
>Severity:       non-critical
>Priority:       medium
>Responsible:    kern-bug-people
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Sun Jun 28 00:25:00 +0000 2020
>Originator:     Andrew Geng
>Release:        libhfs.c v1.15
>Organization:
>Environment:
Linux delia 5.5.8-arch1-1 #1 SMP PREEMPT Fri, 06 Mar 2020 00:57:33 +0000 x86_64 GNU/Linux
>Description:
I have a directory on what appears to be a case-sensitive HFS+ volume containing subdirectories "Ångstrom" = {'A', 0x030a, 'n', 'g', 's', 't', 'r', 'o', 'm'} and "Azide" (among others). When attempting to list the contents of "Ångstrom":

ls: cannot access 'Ångstrom': No such file or directory

In the tree, Azide is just before Ångstrom; but hfslib_compare_catalog_keys_bc claims that Azide > Ångstrom, so hfslib_find_catalog_record_with_key concludes that Ångstrom is not present.
>How-To-Repeat:
On a case-sensitive HFS+ volume, create a directory structure

somewhere
somewhere/Azide
somewhere/Ångstrom

and attempt to ls somewhere/Ångstrom.

(Untested; we no longer have the machine that wrote this volume.)
>Fix:
Patch exists, submitted to a project that bundles libhfs.c:

https://github.com/0x09/hfsfuse/pull/12

It carries out the FIXME in hfslib_compare_catalog_keys_bc, replacing the use of memcmp with a naive entry-by-entry comparison of the uint16_t arrays. (Because a memcmp on a little-endian machine will compare the lower byte of each uint16_t first.)

The tradeoff is that we lose any clever speedups the compiler has for memcmp. Hopefully that's worth it.

Home	PR Database Search