SDXC UHS-I card with exfat FS corrupted on Android Orio (8.0)

In case anyone else hits this issue I thought I'd document it here:

Whenever I get a new phone, I buy a new mico-SD Card and transfer all my Pictures, Music and useful stuff from my old card to my new. I have just been hit by rather annoying issue. When I plugged the SDXC card in to my Moto G6 (Orio 8.0.0) it gave corrupt card with the only option be to reformat it.

Turns out that the issue is a 16 bit UTF filename in the file system - something created on my old Galaxy phone with place names in picture filenames.

The exfat (1.2.5-2) driver that I installed on my Linux laptop:

apt install exfat-fuse exfat-utils

would give the following on an fsck:

Jun 15 11:25:30 tonydell mount.exfat: illegal UTF-16 sequence
Jun 15 11:25:30 tonydell mount.exfat: failed to convert name to UTF-8

My guess is, this is the same reason the Android device reports the issue as I guess it uses the same FS driver.

So, the fix is to first find the directory that has the file:

1. First mount your card on the unix box
2. Run "find mountdir"
   This will fail with some error message - can't remember exactly but something along the lines of "software abort" or some such. But the key is that it will give you the directory name.
3. The FS is now disabled on linux so:
   umount the card on linux
4. Put the card in to a window laptop and navigate to that directory
5. Windows seems to at least cope with the strange UTF-16 filenames and you can rename all files in the directory that have non-ascii characters in them.
6. Put the sdcard back in your Linux box and run fsck again.
   It should complete cleanly unless you have other directories with the same issue in which case just repeat the process.

If you don't have a windows box (and why should you) you will need to be more careful on transferring the files across - first checking for UTF-16 filenames.

I think this is a potential issue with Linux exfat FS implementation - rather than failing the FS on UTF-16 convert - they should just report the error and map to "?" or some such. Its bizarre that the directory write completes but the read fails.

See: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=847236