Re: [PATCH v2 1/6] fs: Add case sensitivity info to file_kattr

["Chuck Lever" <cel@kernel.org>]

On Fri, Dec 12, 2025, at 4:23 PM, Theodore Tso wrote:
> On Fri, Dec 12, 2025 at 10:08:18AM -0500, Chuck Lever wrote:
>> The unicode v. ascii case folding information was included just as
>> an example. I don't have any use case for that, and as I told Eric,
>> those specifics can be removed from the API.
>> 
>> The case-insensitivity and case-preserving booleans can be consumed
>> immediately by NFSD. These two booleans have been part of the NFSv3
>> and NFSv4 protocols for decades, in order to support NFS clients on
>> non-POSIX systems.
>
> I was worried that some clients might be using this information so
> they could do informed caching --- i,e., if they have "makefile"
> cached locally because the user typed "more < makefile" into their
> Windows Command.exe window, and then later on some program tries to
> access "Makefile" the client OS might decide that they "know" that
> "makefile" and "Makefile" are the same file.  But if that's the case,
> then it needs to have more details about whether it's ASCII versus
> Unicode 1.0 vs Unicode 17.0 case folding that be in use, or there
> might be "interesting" corner cases.

No current version of the NFS protocol can communicate any more than
whether or not filenames are case sensitive and case preserving. Thus
the unicode label idea is nothing NFSD can possibly take advantage of.


> Which is why I've gotten increasingly more sympathetic to Linus's
> position that case folding is Hot Trash.  If it weren't for the fact
> that I really wanted to get Android out of using wrapfs (which is an
> even greater trash fire), I'd be regretting the fact that I helped to
> add insensitive file name support to Linux...

Well I think "Hot Trash" is the general consensus. I'm not thinking
of adding more than the NFS protocol can support. I'm only suggesting
that more /could/ be done if someone has a use case for it.


-- 
Chuck Lever