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:
LC_ALL=C
nor this:
LC_ALL=POSIX
or for that matter:
LC_ALL=en_US.utf8
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?
Zach
smime.p7s
Description: S/MIME cryptographic signature
|