Received: by 2002:a25:8b91:0:0:0:0:0 with SMTP id j17csp2496729ybl; Mon, 20 Jan 2020 04:08:55 -0800 (PST) X-Google-Smtp-Source: APXvYqx/vmXGFH/WqrMm+4am2CKHX59kwKONry4I2J7dWixNmIV3pSUy0e9cb2/bwhNeD9MBO2lj X-Received: by 2002:aca:3354:: with SMTP id z81mr13005528oiz.129.1579522135064; Mon, 20 Jan 2020 04:08:55 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1579522135; cv=none; d=google.com; s=arc-20160816; b=sz0BrkljeaGIzvrYL3aktF8IV/BUfrt72MfUaWAviI8bBEKCw+WQfUwfxGQouKy7Nu gO+cYSPdtTa5s9jaYWk2AfCSifHLX3zxRoorqo/DeXXssAqFQ/LSTVr2xdx0rvpO+cx/ ThWSqBl0yt/ujBbKMDr50uu0sLQhOIFEYNxKLSIo5tPIxxt+4TnvDrHYS5JmQO7w/3Ni Y2M2tr6Vk2QUYA5YEYZ9QC7Py+TJ1urlaSTwc8SmJigQaxI8+7GaDRDx/7tW0nGyaeMQ XGmnDqBhZ7YTT6puqqY924NJpcpyz3Xm2Lf5ZoWJJiTOBbGofkWWC+/rmQ0yx8ZA22im UXJg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :user-agent:message-id:in-reply-to:date:references:subject:cc:to :from; bh=jwuf82UOif0R8kOMaN/uPwNV4iHElCEBF2wdvFbWr58=; b=dz9aNy9fnfbhoUn9AvZFTu5xcobQWDCpK/TixRqevRhPAScuGnzICmbVSw+zEu3dbP 9YJ847986LJ7YCIuCCVX0igfi35oFtsI5iAFyGGdmCzg4sCzvrGkiXXo9fzH536JkUSF /RT2bBxUhqrP/4SaVgUd423KKjUxiAGi7p2p0cF+04wBhUitxyfINLTQTAYtoLPJdZbW kEdu9iAC/CmlZ/C5Uj77VFI/C7KiEbQVj7BIiknoLlgSgWgbxTLdEohij3KySx8VwZ8V mmCGSTkvYIlve5pW3MSq0ttOarsdAF+k+KSHFK++N+ahUXUFwjk1kEyvmF/WfYgvJnmJ 6k0A== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id s16si17945636oih.4.2020.01.20.04.08.43; Mon, 20 Jan 2020 04:08:55 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726860AbgATMHR (ORCPT + 99 others); Mon, 20 Jan 2020 07:07:17 -0500 Received: from mail.parknet.co.jp ([210.171.160.6]:52522 "EHLO mail.parknet.co.jp" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726589AbgATMHR (ORCPT ); Mon, 20 Jan 2020 07:07:17 -0500 Received: from ibmpc.myhome.or.jp (server.parknet.ne.jp [210.171.168.39]) by mail.parknet.co.jp (Postfix) with ESMTPSA id 5745215CBE2; Mon, 20 Jan 2020 21:07:16 +0900 (JST) Received: from devron.myhome.or.jp (foobar@devron.myhome.or.jp [192.168.0.3]) by ibmpc.myhome.or.jp (8.15.2/8.15.2/Debian-16) with ESMTPS id 00KC7Fw9037236 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT); Mon, 20 Jan 2020 21:07:16 +0900 Received: from devron.myhome.or.jp (foobar@localhost [127.0.0.1]) by devron.myhome.or.jp (8.15.2/8.15.2/Debian-16) with ESMTPS id 00KC7Ebd227995 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT); Mon, 20 Jan 2020 21:07:14 +0900 Received: (from hirofumi@localhost) by devron.myhome.or.jp (8.15.2/8.15.2/Submit) id 00KC7CGW227993; Mon, 20 Jan 2020 21:07:12 +0900 From: OGAWA Hirofumi To: Pali =?iso-8859-1?Q?Roh=E1r?= Cc: linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org, "Theodore Y. Ts'o" , Namjae Jeon , Gabriel Krisman Bertazi Subject: Re: vfat: Broken case-insensitive support for UTF-8 References: <20200119221455.bac7dc55g56q2l4r@pali> <87sgkan57p.fsf@mail.parknet.co.jp> <20200120110438.ak7jpyy66clx5v6x@pali> Date: Mon, 20 Jan 2020 21:07:12 +0900 In-Reply-To: <20200120110438.ak7jpyy66clx5v6x@pali> ("Pali =?iso-8859-1?Q?Roh=E1r=22's?= message of "Mon, 20 Jan 2020 12:04:38 +0100") Message-ID: <875zh6pc0f.fsf@mail.parknet.co.jp> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Pali Roh?r writes: >> To be perfect, the table would have to emulate what Windows use. It can >> be unicode standard, or something other. > > Windows FAT32 implementation (fastfat.sys) is opensource. So it should > be possible to inspect code and figure out how it is working. > > I will try to look at it. I don't think the conversion library is not in fs driver though, checking implement itself would be good. >> And other fs can use different what Windows use. >> >> So the table would have to be switchable in perfect world (if there is >> no consensus to use 1 table). If we use switchable table, I think it >> would be better to put in userspace, and loadable like firmware data. >> >> Well, so then it would not be simple work (especially, to be perfect). > > Switchable table is not really simple and I think as a first step would > be enough to have one (hardcoded) table for UTF-8. Like we have for all > other encodings. Ignoring if utf8 table is good or not. If the table is not windows compatible or doesn't satisfy other fs's requirement, it also is yet another broken table like now (of course, it would likely be better off). Of course, we can define it as linux implementation limitation though. So yes, I think this work is not simple. >> Also, not directly same issue though. There is related issue for >> case-insensitive. Even if we use some sort of internal wide char >> (e.g. in nls, 16bits), dcache is holding name in user's encode >> (e.g. utf8). So inefficient to convert cached name to wide char for each >> access. > > Yes, this is truth. But this conversion is already doing exFAT > implementation. I think we do not have other choice if we want Windows > compatible implementation. For example, we can cache the both of display name, and upper/lower case name. Anyway, at least, there are some implement options. Thanks. -- OGAWA Hirofumi