[Top] [All Lists]

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

To: Ben Myers <bpm@xxxxxxx>
Subject: Re: [PATCH 05/16] xfs: return the first match during case-insensitive lookup.
From: Dave Chinner <david@xxxxxxxxxxxxx>
Date: Fri, 10 Oct 2014 07:38:14 +1100
Cc: linux-fsdevel@xxxxxxxxxxxxxxx, olaf@xxxxxxx, xfs@xxxxxxxxxxx
Delivered-to: xfs@xxxxxxxxxxx
In-reply-to: <20141009154240.GC1865@xxxxxxx>
References: <20141003214758.GY1865@xxxxxxx> <20141003215542.GD1865@xxxxxxx> <20141006221928.GJ2301@dastard> <20141009154240.GC1865@xxxxxxx>
User-agent: Mutt/1.5.21 (2010-09-15)
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?

> > 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'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?


Dave Chinner

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