Re: Files with non-ASCII names inaccessible after xfs_repair

Zachary Kotlarek
2014-01-15T05:31:13Z

[-- Attachment #1.1: Type: text/plain, Size: 1301 bytes --]

On Jan 14, 2014, at 7:48 PM, Dave Chinner <david@fromorbit.com> 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

[-- Attachment #1.2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 2749 bytes --]

[-- Attachment #2: Type: text/plain, Size: 121 bytes --]