From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1757741Ab0CKMli (ORCPT ); Thu, 11 Mar 2010 07:41:38 -0500 Received: from mail.parknet.co.jp ([210.171.160.6]:50132 "EHLO mail.parknet.co.jp" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1757571Ab0CKMlg (ORCPT ); Thu, 11 Mar 2010 07:41:36 -0500 From: OGAWA Hirofumi To: Philippe De Muyter Cc: linux-kernel@vger.kernel.org Subject: Re: [PATCH vfat] allow retrieving entries with trailing dots References: <20100310123257.GA2899@frolo.macqel> <87d3zc1bjo.fsf@devron.myhome.or.jp> <20100310161429.GA16799@frolo.macqel> <87hboow105.fsf@devron.myhome.or.jp> <20100310235808.GA4353@frolo.macqel> <87bpevryxt.fsf@devron.myhome.or.jp> <20100311120214.GA23767@frolo.macqel> Date: Thu, 11 Mar 2010 21:41:33 +0900 In-Reply-To: <20100311120214.GA23767@frolo.macqel> (Philippe De Muyter's message of "Thu, 11 Mar 2010 13:02:14 +0100") Message-ID: <87y6hzni82.fsf@devron.myhome.or.jp> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1.93 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Philippe De Muyter writes: >> > This is unavoidable. > > We could perhaps reduce the disadvantage by moving the logic (test first > with the trailing dots, and then without if needed) into fat_search_long > instead of putting it in vfat_find as my patch proposal does. This way > the name to find would only be compared once to unrelated entries, > instead of possibly twice as my patch does. > > But therefore I need your help : fat_search_long isn't easy to read/modify. > > The logic could be modified as such : > - if the searched name contains trailing dots, first compare > the truncated part to the same length of the directory entry > - if they are the same, test the length of the rest of the directory entry > - if length_of_rest is 0, this could be the matching entry, > but there could be a better one later; keep searching till the end. > - if length_of_rest is not 0, compare the rest with the trailing dots > - if rests are equal, we have found it; return > - if rests are unequal, continue searching > >> >> We would be able to introduce new mount option to do it if needed. > > A new mount option should be the last programming option. It is better to > automatically do the right thing than to require the user to figure out > he must add a mount option in /etc/fstab or whatever. Remember this is > for hot-plug disks. Sorry, but I'm not thinking this is primary one. So, requiring option for it to avoid disadvantage of normal users, it sounds good. >> This changed vfat_find(), so, this patch will change the behavior of all >> callers more or less. And the behavior seems to be really strange, you >> can remove "a.", but you can't create it? > > Yes, you can remove any existing file, but if you want to create a file, > the name creation rules are kept unchanged. So, creating "a." will > succeed, it will actually be called "a" on disk, but you can still refer > to it as "a." : that will succeed. That's the strange part of the behavior > but that part is already present for compatibility reasons nor you nor me > can do anything about :( > >> The behavior sounds random, right? > > It's a compromise to avoid creating name entries that are not universally > accepted, but to allow accessing existing files and directories. > > The mount option could be useful then to allow the creation of file and > directory names with trailing dot, but consistency between getdents and > stat/open must be automatic. No, this breaks consistency. With this patch, unlink("a."), then open("a.", O_CREAT) and write(), the result depend on existent files. This patch is providing two files on one name. Thanks. -- OGAWA Hirofumi