On Fri, Oct 10, 2014 at 07:38:14AM +1100, Dave Chinner wrote:
> On Thu, Oct 09, 2014 at 10:42:40AM -0500, Ben Myers wrote:
> > On Tue, Oct 07, 2014 at 09:19:28AM +1100, Dave Chinner wrote:
> > > On Fri, Oct 03, 2014 at 04:55:42PM -0500, Ben Myers wrote:
> > > > From: Olaf Weber <olaf@xxxxxxx>
> > > >
> > > > Change the XFS case-insensitive lookup code to return the first match
> > > > found, even if it is not an exact match. Whether a filesystem uses
> > > > case-insensitive lookups is determined by a superblock bit set during
> > > > filesystem creation. This means that normal use cannot create two files
> > > > that both match the same filename.
> > > >
> > > > Signed-off-by: Olaf Weber <olaf@xxxxxxx>
> > >
> > > This is really dependent on whether we want to support mixed
> > > CI/non-CI filesystems, yes? i.e. if we want to support mixed case
> > > setups, then we need to keep the code as it stands?
> > It depends upon what semantics you decide are correct in the mixed case.
> > This is just one solution.
> Ok, so we need this code or somethign very similar to support mixed
> case filesystems. Can you tell us what the other possible solutions
> and semantics have been considered?
There was some discussion of this in the v2 posting of this rfc.
Olaf's "readme" example at the above link is a pretty good example of
what we're facing. And I don't have a good answer for which file to
open. So for now we're just going for the cleanest solution.
> > > What is the downside of keeping the code unchaged and our
> > > options open?
> > The code that is being removed here was for the case when you
> > could have multiple filenames that match for a lookup, which was
> > only possible when the ascii-ci bit was implemented as a mount
> > option.
> Yes, I know what the code did - it allowed us to support mixed case
> ascii-ci filesystems. All you've said is "if we remove mixed case
> support the code is cleaner" but not addressed the issue at hand.
I also tried to explain that as the codebase stands today, removal of
this code does not represent a loss of functionality. It is dead code.
> I'll try asking the same question a different way: if we keep this
> code, will it work for mixed case unicode filesystem or do we have
> to re-implement mixed case matching differently?
If you definately want to keep this code around I'll look into this, but
right now I don't have plans to extend the patchset to support mixed
case insensitivity in a single filesystem.