> 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 _______________________________________________ xfs mailing list xfs@xxxxxxxxxxx http://oss.sgi.com/mailman/listinfo/xfs
