linux-kernel - Re: [GIT PULL] bcachefs fixes for 6.15-rc4

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <937126029.191.1746075350593@mail.carlthompson.net>
Date: Wed, 30 Apr 2025 21:55:50 -0700 (PDT)
From: "Carl E. Thompson" <list-bcachefs@...lthompson.net>
Cc: linux-bcachefs@...r.kernel.org, linux-fsdevel@...r.kernel.org,
	linux-kernel@...r.kernel.org
Subject: Re: [GIT PULL] bcachefs fixes for 6.15-rc4

Here's a probably silly question from someone who isn't a kernel developer: What's the point of all this effort to do case-folding at the Linux kernel level anyway?

Linux and UNIX applications don't need it. Certainly nothing performance critical uses it.

If certain Windows games and applications need case-folding and Wine wants to let Linux users run those applications then let Wine handle case-folding at *their* layer since they have to implement Microsoft's filesystem APIs / ABIs anyway.

Or implement loop-device namespaces and let users mount their own exFAT images for the Wine case and contain the evilness to *that* driver.

I can think of no *good* reason why a modern *Linux* filesystem needs case-folding. (I don't consider it being a challenging problem to "solve" to be a good reason. Neither is because someone is paying you to help their narrow use case if it means making more common cases less optimal or more complex.)

I do very much agree with a point that I think Kent was making that humans beings expect case-folding in their interactions with computers. That's true. But the human interaction case doesn't need to be handled in the kernel, does it? When I click "Open" in my editor and start typing to find a file it *already* case folds for me and it does it without filesystem support. Same thing for my file browser. Same thing for the 'ls' command in my configuration. We already have tons of options in user space for this.

Thanks,
Carl

PS: And as long as folks are opining on the causes and history of this problem maybe go right to the origin: whomever first made the idiotic decision that computers should internally represent an uppercase 'A' with a different code than a lowercase 'a'. Sure that probably made writing routines to display a limited set of glyphs on ancient OSs a little easier but logically it makes no sense. *It's the same letter!* I guess I can be thankful they didn't add separate codes for italics, bold and serif versions of the letters too. (But at least one company *did* add reversed foreground/background letters to there version of ASCII.) There should only be one code for each letter and everything else should be up to user space. 

> On 2025-04-30 8:32 PM PDT H. Peter Anvin <hpa@...or.com> wrote:
> 
>  
> On April 30, 2025 8:12:20 PM PDT, Linus Torvalds <torvalds@...ux-foundation.org> wrote:
> >On Wed, 30 Apr 2025 at 19:48, H. Peter Anvin <hpa@...or.com> wrote:
> >>
> >> It is worth noting that Microsoft has basically declared their
> >> "recommended" case folding (upcase) table to be permanently frozen (for
> >> new filesystem instances in the case where they use an on-disk
> >> translation table created at format time.)  As far as I know they have
> >> never supported anything other than 1:1 conversion of BMP code points,
> >> nor normalization.
> >
> >So no crazy 'ß' matches 'ss' kind of thing? (And yes, afaik that's
> >technically wrong even in German, but afaik at least sorts the same in
> >some locales).
> >
> >Because yes, if MS basically does a 1:1 unicode translation with a
> >fixed table, that is not only "simpler", I think it's what we should
> >strive for.
> >
> >Because I think the *only* valid reason for case insensitive
> >filesystems is "backwards compatibility", and given that, it's
> >_particularly_ stupid to then do anything more complicated and broken
> >than the thing you're trying to be compatible with.
> >
> >I hope to everything holy that nobody ever wants to be compatible with
> >the absolute garbage that is the OSX HFS model.
> >
> >Because the whole "let's actively corrupt names into something that is
> >almost, but not exactly, NFD" stuff is just some next-level evil
> >stuff.
> >
> >            Linus
> >
> 
> I suspect the NFD bit in HFS comes from the use of decomposed characters in the 8-bit character systems of MacOS Classic.