> That's easy actually, since ASCII is a 7-bit code it can only contain char
> values between 0-127 or in other words the highest bit must not be set in any
> char. But probably this strict check could break other stuff.
As long as you exclude extended ascii and data corruption, I don't know what
else that could break. My guess would be that ASCII as understood by XFS users
would be the 0-127 and not the various mix of extensions. If you want to
include support for extended ascii...then I don't think there's any way to
determine non-probabilistically the difference between ASCII and UTF based on
the data itself.
I have no idea what the current behavior is with respect to extended ASCII
(whether it's supported, or works, or anything).
From: xfs-bounces@xxxxxxxxxxx [mailto:xfs-bounces@xxxxxxxxxxx] On Behalf Of
Sent: Thursday, January 16, 2014 2:56 PM
Subject: Re: Files with non-ASCII names inaccessible after xfs_repair
> The utf-8 patches add a "is this valid utf-8" check to all the
> operations that care. We could probably do that for the ASCII-CI stuff
> if you can define what ASCII means....
That's easy actually, since ASCII is a 7-bit code it can only contain char
values between 0-127 or in other words the highest bit must not be set in any
char. But probably this strict check could break other stuff.
xfs mailing list