By default vfat file systems are mounted using ASCII, which is different to the kernel default of iso8859-1. This results in errors when copying any non ASCII file names. By setting CONFIG_FAT_DEFAULT_IOCHARSET="isoi8859-1" in config-generic, it would at least preserve the file names, as there are no invalid characters in this encoding. Doing this would also match the kernel default (and the `man 8 mount` information too).
I looked around in bugzilla/cvs/git history for why we have this set to ascii and didn't find any clear cut explanation. It simply has always been this way. However, vfat volumes are mounted with iocharset=ascii and the utf8 option as well. Shouldn't that allow non-ascii filenames? Can you provide the output of: cat /proc/self/mounts | grep fat and the errors you are seeing when copying non-ascii filenames?
I think the utf8 option overrides the iocharset one? From reading the man page, utf8 means utf8 is stored on the file system, whereas iocharset means 16 bit unicode? Note using utf8 is more restrictive than iocharset=iso8859-1 as utf8 mode will validate utf8 before writing, whereas iso8859-1 will just write all bytes. Anyway this isn't about changing away from the utf8 validation (that's could be a good default). Note utf8 is _not_ set here by default for loop back mounts. So some examples: $ truncate -s10M vfat.img $ mkfs.vfat vfat.img # mount vfat.img vfat # grep fat /proc/self/mounts /dev/loop0 /home/.../vfat vfat rw,relatime,fmask=0022,dmask=0022,codepage=cp437,iocharset=ascii,shortname=mixed,errors=remount-ro 0 0 # touch útf8 # (note file will not be created) touch: setting times of `útf8': No such file or directory # touch ascii # cd .. # umount vfat # mount -o utf8 vfat.img vfat # cd vfat # touch útf8 # touch $(echo isó | iconv -t iso-8859-1) touch: setting times of `is\363': No such file or directory # cd .. # umount vfat # mount -o iocharset=iso8859-1 vfat.img vfat # cd vfat # touch útf8 # touch $(echo isó | iconv -t iso8859-1)
This bug appears to have been reported against 'rawhide' during the Fedora 19 development cycle. Changing version to '19'. (As we did not run this process for some time, it could affect also pre-Fedora 19 development cycle bugs. We are very sorry. It will help us with cleanup during Fedora 19 End Of Life. Thank you.) More information and reason for this action is here: https://fedoraproject.org/wiki/BugZappers/HouseKeeping/Fedora19