On Wed, 10 Sept 2025 at 13:10, Jeff Layton <jlayton@xxxxxxxxxx> wrote: > > On Tue, 2025-09-09 at 18:06 +0200, Cedric Blancher wrote: > > On Tue, 10 Jun 2025 at 07:34, Christoph Hellwig <hch@xxxxxxxxxxxxx> wrote: > > > > > > On Mon, Jun 09, 2025 at 10:16:24AM -0400, Chuck Lever wrote: > > > > > Date: Wed May 21 16:50:46 2008 +1000 > > > > > > > > > > dcache: Add case-insensitive support d_ci_add() routine > > > > > > > > My memory must be quite faulty then. I remember there being significant > > > > controversy at the Park City LSF around some patches adding support for > > > > case insensitivity. But so be it -- I must not have paid terribly close > > > > attention due to lack of oxygen. > > > > > > Well, that is when the ext4 CI code landed, which added the unicode > > > normalization, and with that another whole bunch of issues. > > > > Well, no one likes the Han unification, and the mess the Unicode > > consortium made from that, > > But the Chinese are working on a replacement standard for Unicode, so > > that will be a lot of FUN =:-) > > > > > > > That being said no one ever intended any of these to be exported over > > > > > NFS, and I also question the sanity of anyone wanting to use case > > > > > insensitive file systems over NFS. > > > > > > > > My sense is that case insensitivity for NFS exports is for Windows-based > > > > clients > > > > > > I still question the sanity of anyone using a Windows NFS client in > > > general, but even more so on a case insensitive file system :) > > > > Well, if you want one and the same homedir on both Linux and Windows, > > then you have the option between the SMB/CIFS and the Windows NFSv4.2 > > driver (I'm not counting the Windows NFSv3 driver due lack of ACL > > support). > > Both, as of September 2025, work fine for us for production usage. > > > > > > Does it, for example, make sense for NFSD to query the file system > > > > on its case sensitivity when it prepares an NFSv3 PATHCONF response? > > > > Or perhaps only for NFSv4, since NFSv4 pretends to have some recognition > > > > of internationalized file names? > > > > > > Linus hates pathconf any anything like it with passion. Altough we > > > basically got it now with statx by tacking it onto a fast path > > > interface instead, which he now obviously also hates. But yes, nfsd > > > not beeing able to query lots of attributes, including actual important > > > ones is largely due to the lack of proper VFS interfaces. > > > > What does Linus recommend as an alternative to pathconf()? > > > > Also, AGAIN the question: > > Due lack of a VFS interface and the urgend use case of needing to > > export a case-insensitive filesystem via NFSv4.x, could we please get > > two /etc/exports options, one setting the case-insensitive boolean > > (true, false, get-default-from-fs) and one for case-preserving (true, > > false, get-default-from-fs)? > > > > So far LInux nfsd does the WRONG thing here, and exports even > > case-insensitive filesystems as case-sensitive. The Windows NFSv4.1 > > server does it correctly. > > > > Ced > > I think you don't want an export option for this. > > It sounds like what we really need is a mechanism to determine whether > the inode the client is doing a GETATTR against lies on a case- > insensitive mount. <rant> It might sound rude, but after reading that I had to empty my bottle of bromhydrate de scopolamine renaudin. The topic of returning the correct booleans for fattr_case_insensitive and fattr_case_preserving in Linux has been running in circles since (at least) 2008, covering all kinds of bug reports (CITI, Suse, RH, ....) and mailing lists. So far NOTHING ever happened, except "more research", "no time" and so on, while other platforms like the Windows Server 2019 platform and the Exceed/OpenText NFS4 server just did it correctly. Exceed NFS client handles it correctly. </rant> Ced -- Cedric Blancher <cedric.blancher@xxxxxxxxx> [https://plus.google.com/u/0/+CedricBlancher/] Institute Pasteur
