> 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).
Cheers,
-Shaun
-----Original Message-----
From: xfs-bounces@xxxxxxxxxxx [mailto:xfs-bounces@xxxxxxxxxxx] On Behalf Of
Michael Weissenbacher
Sent: Thursday, January 16, 2014 2:56 PM
To: xfs@xxxxxxxxxxx
Subject: Re: Files with non-ASCII names inaccessible after xfs_repair
Hi!
>
> 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.
cheers,
Michael
_______________________________________________
xfs mailing list
xfs@xxxxxxxxxxx
http://oss.sgi.com/mailman/listinfo/xfs
|