Message-ID: <20100313113150.GA11907@frolo.macqel>
Date:	Sat, 13 Mar 2010 12:31:50 +0100
From:	Philippe De Muyter <phdm@...qel.be>
To:	OGAWA Hirofumi <hirofumi@...l.parknet.co.jp>
Cc:	linux-kernel@...r.kernel.org
Subject: Re: [PATCH vfat] allow retrieving entries with trailing dots

Hello Ogawa,

On Thu, Mar 11, 2010 at 09:41:33PM +0900, OGAWA Hirofumi wrote:
> Philippe De Muyter <phdm@...qel.be> 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.

To avoid that, we could remember that we have found a filename with a trailing
dot (in that directory or in the whole disk), and if that's the case then
we are allowed to create filenames with trailing dots.

Philippe
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists