From: Philippe De Muyter <phdm@macqel.be>
To: OGAWA Hirofumi <hirofumi@mail.parknet.co.jp>
Cc: linux-kernel@vger.kernel.org
Subject: Re: [PATCH vfat] allow retrieving entries with trailing dots
Date: Sat, 13 Mar 2010 12:31:50 +0100 [thread overview]
Message-ID: <20100313113150.GA11907@frolo.macqel> (raw)
In-Reply-To: <87y6hzni82.fsf@devron.myhome.or.jp>
Hello Ogawa,
On Thu, Mar 11, 2010 at 09:41:33PM +0900, OGAWA Hirofumi wrote:
> Philippe De Muyter <phdm@macqel.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
next prev parent reply other threads:[~2010-03-13 11:32 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-03-10 12:32 [PATCH vfat] allow retrieving entries with trailing dots Philippe De Muyter
2010-03-10 14:44 ` OGAWA Hirofumi
2010-03-10 16:14 ` Philippe De Muyter
2010-03-10 17:16 ` OGAWA Hirofumi
2010-03-10 23:58 ` Philippe De Muyter
2010-03-11 9:26 ` OGAWA Hirofumi
2010-03-11 12:02 ` Philippe De Muyter
2010-03-11 12:41 ` OGAWA Hirofumi
2010-03-13 11:31 ` Philippe De Muyter [this message]
2010-03-13 13:06 ` OGAWA Hirofumi
2010-03-14 10:39 ` [PATCH vfat] IOMEGA network drive compatibility Philippe De Muyter
2010-03-14 11:17 ` OGAWA Hirofumi
2010-03-14 14:13 ` Philippe De Muyter
2010-03-14 14:52 ` OGAWA Hirofumi
-- strict thread matches above, loose matches on Subject: below --
2009-03-19 18:11 [PATCH] parport netmos 9845 & 9855 1P4S fixes Philippe De Muyter
2009-03-23 8:50 ` Philippe De Muyter
2009-03-23 14:00 ` Philippe De Muyter
2009-09-25 19:46 ` [PATCH RFC] vfat and Simon_&_Garfunkel-Wednesday_Morning,_3_a.m Philippe De Muyter
2009-09-29 10:05 ` OGAWA Hirofumi
2009-09-29 10:25 ` Philippe De Muyter
2009-09-29 22:43 ` Philippe De Muyter
2009-09-30 11:02 ` OGAWA Hirofumi
2009-09-30 22:19 ` Philippe De Muyter
2009-10-01 10:42 ` OGAWA Hirofumi
2010-02-08 9:39 ` [PATCH vfat] allow retrieving entries with trailing dots Philippe De Muyter
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20100313113150.GA11907@frolo.macqel \
--to=phdm@macqel.be \
--cc=hirofumi@mail.parknet.co.jp \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox