Message-ID: <20100310235808.GA4353@frolo.macqel>
Date:	Thu, 11 Mar 2010 00:58:08 +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

Hi Ogawa,

On Thu, Mar 11, 2010 at 02:16:26AM +0900, OGAWA Hirofumi wrote:
> Philippe De Muyter <phdm@...qel.be> writes:
> 
> >> This introduces unneeded directory-parse to standard one.  And for
> >
> > No.  There will only be a second parse if someone is looking for a filename
> > with a trailing dot, and it is not found (*).  I there is no trailing dot in qname, only the first fat_search_long will be called, because len after vfat_striptail_len would be equal to qname->len.
> 
> Yes, I'm saying about trailing-dot filename case. Any disadvantage to
> standard one is unacceptable to workaround.

This is unavoidable.
Let me explain again, with better words I hope,
IOMEGA firmware allows creation of files/directories whose name have
trailing dots.

When I connect such a disk (which is vfat-formatted) via USB to my
linux computer, I want consistency between what getdents says and what
open or stat will do : if getdents says there is a file called "a.",
currently open("a.") and stat("a.") fail with ENOENT No such file or directory.
I would like open("a.") or stat("a.") to succeed.  Nothing more.
For that, I need to first search for the not truncated name.  If that fails
and the filename can be truncated then and only then, try again with the
truncated name.  I cannot let getdents truncate the name, because there 
could also be a different file really called "a".

There would be no advantage in making the change in fat_search_long,
because while searching for "a.", even if it finds a "a" entry, it must
continue till the end of the directory to be sure there is no "a.".

> 
> >> IO-MEGA, this wouldn't provide proper filename handling.
> >
> > For accessing IO-MEGA disk in read mode, this is perfect.  I didn't want
> > to replicate IO-MEGA write behaviour here, only fix the read behaviour for
> > such simple commands as 'ls', 'find' and all the directory browsers.
> >
> >> If it wants to handle the tailing-dot as a part of filename, it
> >> shouldn't be able to access to the stripped-dots filename. (For simple
> >> example, I guess you can't do "mv a a." with this patch.)
> >
> > As I explained above, I only fix read-access on IO-MEGA drives, while
> > preserving standard behaviour for write mode.
> >
> > But I'll try your testcase asap.  Which behaviour do you expect ?
> > I would expect a no-op, because I did not change the write-behaviour.
> 
> Those sound like strange.  Well, I expect there is no any change to
> standard one for IO-MEGA.
> 
> And I can't see what is your read-access mean in here. What did this
> expect to behave like e.g. following operations,

Sorry bad wording. I meant I do not want to change the behaviour for file
creation, only to fix the behaviour while accessi8ng existing files.

> 
> 	$ ls
>         a.. a. a
>         $ rm -rf *
> 
>         $ ls
>         a..
>         $ touch a.
>         $ touch a
> ...
> 
> I assumed you want to define "a." and "a" are different name on
> "mv a a.", and _totally_.

For file creation and renaming, I want to introduce no change, because there
is no problem.  If one wants to create a "a." file on a IO-MEGA disk suing
linux and USB, it is currently called "a", and that will remain exactly the
same.

Best regards

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