Files with non-ASCII names inaccessible after xfs_repair

[Zachary Kotlarek]

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2749 bytes
Desc: not available
URL: <http://oss.sgi.com/pipermail/xfs/attachments/20140114/2471f76a/attachment.p7s>