[Top] [All Lists]

Re: Files with non-ASCII names inaccessible after xfs_repair

To: Dave Chinner <david@xxxxxxxxxxxxx>
Subject: Re: Files with non-ASCII names inaccessible after xfs_repair
From: Zachary Kotlarek <zach@xxxxxxxxxxxx>
Date: Tue, 14 Jan 2014 21:30:57 -0800
Cc: xfs@xxxxxxxxxxx
Delivered-to: xfs@xxxxxxxxxxx
Dkim-signature: v=1; a=rsa-sha256; c=simple/simple; d=kotlarek.com; s=default; t=1389763862; bh=llORv4nx0euE3qAzizqrMFkPMqXyS9oJ8PGOUBUqEMk=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Message-Id:References:To; b=imjtfo3yJUyNdms5V4WVZ/uyIYPjAapGdNU1KdX7elSz2Dz0weM5WaLO1jhvVl3PA odrLNDxy4q3yI+VJZB3gvVKy44AKArmVLqSdZ0b+1LXZOh1cLFhugECPmxZFdo/CmD GVoEjN5JE8xM7utiABEDnGllDcsk9mSP6Cnkv1AU=
In-reply-to: <20140115034803.GT3469@dastard>
References: <20140113015007.GC3469@dastard> <EDB09149-717F-4089-9C21-1D342CF77A7D@xxxxxxxxxxxx> <20140113031947.GG3469@dastard> <E2EE0AEA-ED22-4D3B-8550-88F2ED1F8314@xxxxxxxxxxxx> <20140113192732.GI3469@dastard> <0E45339E-04C4-4775-B6B0-FC55245B0AED@xxxxxxxxxxxx> <20140114022414.GM3469@dastard> <BE0C947E-37DE-4CA1-B120-59B95E1E8EB8@xxxxxxxxxxxx> <20140115015350.GR3469@dastard> <61E74CEF-8244-4E90-BA7D-91D54DADC3C1@xxxxxxxxxxxx> <20140115034803.GT3469@dastard>
On Jan 14, 2014, at 7:48 PM, Dave Chinner <david@xxxxxxxxxxxxx> wrote:

> It's called *ASCII* Case Insensitivity for a reason: it doesn't
> support anything other than ASCII. So your usage is not actually
> supported at all, hence it's no surprise that it has caused
> breakage.

Okay. Thanks for the explanation.

FWIW, I read “ASCII-only case-insensitive” to mean “only case-insensitive for 
ASCII” as in ñ and Ñ would not match each other. If it actually means “anything 
other than ASCII is subject to complete breakage” a more nuanced explanation in 
the man page might be desirable.

I don’t suppose there’s any way to disable that setting short of creating a new 
file system?

> I suspect that the way to fix your filesystem is to run xfs_repair
> under a "C" locale so that the glibc tolower() function behaves the
> same way the kernel behaves and so the hashes calculated by
> xfs_repair match the what the kernel thinks is correct.

Neither this:
nor this:
or for that matter:
made any difference. And my default was already POSIX.

Any other thoughts?

Theoretically I could find the expected hashvals and overwrite them with 
xfs_db, right? Or at least unlink the files so I can reclaim the disk space?


Attachment: smime.p7s
Description: S/MIME cryptographic signature

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