[Top] [All Lists]

Re: [PATCH 05/16] xfs: return the first match during case-insensitive lo

To: Dave Chinner <david@xxxxxxxxxxxxx>
Subject: Re: [PATCH 05/16] xfs: return the first match during case-insensitive lookup.
From: Ben Myers <bpm@xxxxxxx>
Date: Tue, 14 Oct 2014 10:04:05 -0500
Cc: linux-fsdevel@xxxxxxxxxxxxxxx, olaf@xxxxxxx, xfs@xxxxxxxxxxx
Delivered-to: xfs@xxxxxxxxxxx
In-reply-to: <20141009203814.GB4376@dastard>
References: <20141003214758.GY1865@xxxxxxx> <20141003215542.GD1865@xxxxxxx> <20141006221928.GJ2301@dastard> <20141009154240.GC1865@xxxxxxx> <20141009203814.GB4376@dastard>
User-agent: Mutt/1.5.20 (2009-06-14)

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.


<Prev in Thread] Current Thread [Next in Thread>