[Verizon Samsung Galaxy S III] HMkX2:
Why we have 15 competing standards... "Never attribute to malice that which is adequately explained by stupidity."

Btw, this file acts strangely on my device, I couldn't see it in windows explorer during plugin and It wouldn't copy to my sd card even though other files seem to be copying fine.​

Any files you create on the device without "Rescanning for media" will not be visible in the MTP (Mass Tranfer Protocol) "MP3 player-like" abstracted FUSE filesystem. (One reason why people want UMS (USB Mass Storage) "hard drive-like" support, you see things immediately/it's faster.) Get a free program called SDrescan from Google Play, or run the command below(?), to update the MTP index and see files you create ON the device.

am broadcast -a android.intent.action.MEDIA_MOUNTED -d file://$SECONDARY_STORAGE
am broadcast -a android.intent.action.MEDIA_MOUNTED -d file:///storage/sdcard0

...let me know if you need anything else :) Quick question: If I shut the phone down and pull the SD, can I turn the phone back on and use it without the SD while I load the SD up with files, then power off, re-insert the SD and power on again? (like will it automount again?)​

Yes, the mount script will simply fail and there will be a silent error. (I need to code some error checking if you insert a non-exfat card...)

Like I said, if you could intentionally re-corrupt the header by using Storage Manager to "Unmount SD" then "Mount SD", then the DD command, (and rescanning media to copy the file off!) I'd appreciate it. Although, I have a second idea of how to get around that problem in mind.....

Thanks but I think the bottom line is (1) there is no working open source exfat.fsck anyway and (2) headers are unique per-device. The proper fix is re-coding vold to not run fsck.msdos on a fsck.exfat card.

Oddly enough, I switched to FAT32 even though I'm on a TouchWiz ROM, cause exFAT does not use alternating file allocation tables. When exFAT gets borked, it getse that wa super borked and you have to use chkdsk (or some other brutish method) to retrieve files. When FAT32 gets borked, you can load the last tabls working and elegantly pull your files off the card (no need to muddle through a pile of chkdsk files and find the correct extensions).

Any possibility that this method could be used to mount a more robust file system like ext[2,3,4]? Journaling would be nice. Or some transaction safe file system.​

Yep, that is all 100% true. But I've lost files on fat32 drives as well - and I'd hardly call multiple file tables elegant, especially when they become desynced. :) NTFS would be a better fix, except for the fact it is a magnetic-media filesystem with journaling/timestamps/excessive writes, and exFAT was designed for flash media in the first place!! Even EXT4 writes too much, EXT2 or EXT4 with journaling disabled is a better solution for integrity, but much worse for flash-life. Nowadays, the value of error-recovery outweighs the limited media life. (This discussion comes up a lot in custom Linux firmwares for routers: DD-WRT NVRAM/Flashdrives)

Shardul_seth, the gentleman that compiled these binaries, has made a package for full NTFS support already using ntfs-fuse3g. (<- link) NTFS-3g is very mature/stable at this point, and installation for our devices is even simpler since we already have FUSE support in the kernel. However, his scripts are to mount USB, not the SD card. Mine does the SD card - all those ADB workarounds - so absolutely could be adapted for mounting NTFS cards. I will work on that when I have some time -- I'd need to figure out how to identify a NTFS card on header alone.

Again, all these methods are HACKS, proper support should be added in the kernel at some point. Someone actually has, and I've been cheering for him. He added EXT4 support to CM10.1, his post and code are here. However, he says it "stalled in code review". For the time being, you have to do all this manually.