Bug 825726

Summary:	CONFIG_FAT_DEFAULT_IOCHARSET default should be iso8859-1
Product:	[Fedora] Fedora	Reporter:	Pádraig Brady <p>
Component:	kernel	Assignee:	Kernel Maintainer List <kernel-maint>
Status:	NEW ---	QA Contact:	Fedora Extras Quality Assurance <extras-qa>
Severity:	unspecified	Docs Contact:
Priority:	unspecified
Version:	rawhide	CC:	gansalmon, itamar, jonathan, kernel-maint, madhu.chinakonda
Target Milestone:	---
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:		Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Pádraig Brady 2012-05-28 09:46:22 UTC

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).

Comment 1 Josh Boyer 2012-08-10 16:08:40 UTC

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?

Comment 2 Pádraig Brady 2012-08-10 17:16:48 UTC

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)

Comment 3 Fedora End Of Life 2013-04-03 15:40:19 UTC

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