From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id F2B3B27056D for ; Fri, 12 Dec 2025 21:24:31 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=18.9.28.11 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1765574674; cv=none; b=VJeZ3VGmb38VOnJoSdYxZct439AfB/7g8RVOFveb7Bqy9ySGJ015PkI9QgbgqhNbi1xZ5YZ3QEEeyfp49/loADIu/OvaM3z2gcBzXhqDjONt5oETzFiaX8rHgjC3GCHqqjt8I5tFo6m2qYF+uHYoZqr04QmEZl9L3suLXmDQmMU= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1765574674; c=relaxed/simple; bh=X/4Z7SrDuVXWWE62ndZmLPG3EeTgZBdcPp/qNqK+1RY=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=iUFTZYuNNXCMsXE2SBP+iRADUT/r+YLdUByHeM8YoGr/9fgnEwgkNQrHG4eFAdFnIGW5uwMBa2P0hXrCgxej18ZxmgiPxTxrrmTbaRiaDWjbF6XCvKptzyyrMG1sBoUwCuCApeGl72i1CvIjOqyiz6+tcHrF4lkxslLYu4baaS0= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=mit.edu; spf=pass smtp.mailfrom=mit.edu; dkim=pass (2048-bit key) header.d=mit.edu header.i=@mit.edu header.b=CYOfenLP; arc=none smtp.client-ip=18.9.28.11 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=mit.edu Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=mit.edu Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=mit.edu header.i=@mit.edu header.b="CYOfenLP" Received: from macsyma.thunk.org (fs96f9c61d.tkyc509.ap.nuro.jp [150.249.198.29]) (authenticated bits=0) (User authenticated as tytso@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 5BCLNuWR014791 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 12 Dec 2025 16:23:59 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mit.edu; s=outgoing; t=1765574641; bh=qHLet6Tl+yPkw/ylxl3cL1yEvDFcpp5ou1YH4RSNVm8=; h=Date:From:Subject:Message-ID:MIME-Version:Content-Type; b=CYOfenLPVkZm2rBcGLhUDM1NJUZvmOGO1Vx6gG1fkCpSmD40VRP4qK7RXVy5M2Im9 Y1BO2zlsRf6PcSft6qPt6wumrWlg637b+ZMT5epch/H3YyaPfHVczFTl+rt10EeqcV IUY8u8uN8fxKj7pj2dqVhk5UHt1evm5cSzF3vceqEExy3TyH5ynWc6kYn0iDnvcqeC 4C7sOD4lwFuf5+8S4Ppi4CQcvBwHoj7fvqE4CAMqyz7pOYVuHli4OBK6gvMlD1kE5Y 23uyKBfEwHnkvhNCiZJLVtlAzjVrFOA8Pty5/3+mWVt47WQr+FkEuPP+1kcjpBWSbL LwgE0hQiuUg4Q== Received: by macsyma.thunk.org (Postfix, from userid 15806) id 0C0314FCD4B2; Sat, 13 Dec 2025 06:23:55 +0900 (JST) Date: Sat, 13 Dec 2025 06:23:54 +0900 From: "Theodore Tso" To: Chuck Lever Cc: Eric Biggers , Alexander Viro , Christian Brauner , linux-fsdevel@vger.kernel.org, linux-ext4@vger.kernel.org, linux-nfs@vger.kernel.org, linux-kernel@vger.kernel.org, hirofumi@mail.parknet.co.jp, almaz.alexandrovich@paragon-software.com, adilger.kernel@dilger.ca, Volker.Lendecke@sernet.de, Chuck Lever Subject: Re: [PATCH v2 1/6] fs: Add case sensitivity info to file_kattr Message-ID: <20251212212354.GA88311@macsyma.local> References: <20251211152116.480799-1-cel@kernel.org> <20251211152116.480799-2-cel@kernel.org> <20251211234152.GA460739@google.com> <9f30d902-2407-4388-805b-b3f928193269@app.fastmail.com> <20251212021834.GB65406@macsyma.local> Precedence: bulk X-Mailing-List: linux-ext4@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: 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. 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... - Ted