|Summary:||usb sticks with FAT filesystem don't use utf8|
|Product:||[Fedora] Fedora||Reporter:||Roland Wolters <roland.wolters>|
|Component:||hal||Assignee:||John (J5) Palmieri <johnp>|
|Status:||CLOSED CURRENTRELEASE||QA Contact:|
|Version:||4||CC:||chaghi, jkeck, wtogami|
|Fixed In Version:||0.5.2-2.fc4.1||Doc Type:||Bug Fix|
|Doc Text:||Story Points:||---|
|Last Closed:||2006-01-30 22:25:40 UTC||Type:||---|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
|Cloudforms Team:||---||Target Upstream Version:|
Description Roland Wolters 2005-07-07 22:20:37 UTC
From Bugzilla Helper: User-Agent: Mozilla/5.0 (compatible; Konqueror/3.4; Linux 2.6.12-1.1387_FC4) KHTML/3.4.1 (like Gecko) Description of problem: I was used from fc3 that a usb stick with FAT filesystem is mounted utf8. In this case I was able for example to read the german umlauts. But now in fc4 it is not mounted with utf8 but with ascii. I tried to solve the problem with adding <merge key="volume.policy.mount_option.iocharset=utf8" type="bool">false</merge> <merge key="volume.policy.mount_option.shortname=mixed" type="bool">true</merge> to all FAT-lines in /usr/share/hal/fdi/policy/10osvendor/10-storage-policy.fdi , analogue to a concept given here: https://www.redhat.com/archives/fedora-list/2005-June/msg01903.html But it didn't work. It is very important because sometimes I need to exchange files with Windows 2000 Server machines, and they mount the stick with utf8, too! Version-Release number of selected component (if applicable): hal-0.5.2-2 How reproducible: Always Steps to Reproduce: 1. try to add the given lines to /usr/share/hal/fdi/policy/10osvendor/10-storage-policy.fdi 2. mount a FAT-filesystem usb stick with utf8 encoded files 3. see that the system is not mounted with utf8 Actual Results: The filesystem is mounted with ascii charset, not with utf8 Expected Results: It should be mounted with utf8 charset (and option mixed), not with ascii. Additional info:
Comment 1 Roland Wolters 2005-07-14 02:15:18 UTC
I misspelled the first line: <merge key="volume.policy.mount_option.iocharset=utf8" type="bool">false</merge> must be <merge key="volume.policy.mount_option.iocharset=utf8" type="bool">true</merge>. With that line the mount of the vfat Filesystems goes right. But the original problem that the standard is not utf8 or usc-2 compatible in any way still exists!
Comment 2 Roland Wolters 2005-07-17 21:30:21 UTC
Ok, I've talked to some people, they told me that this problem is a problem of the kernel, not of hal, so I changed this to 'Component: kernel' The Problem: the kernel does not uses the standard-NLS while mounting vfat filesystems, although $ grep NLS /boot/config-2.6.12-1.1390_FC4 [...] CONFIG_NLS=y CONFIG_NLS_DEFAULT="utf8" [...] CONFIG_NLS_UTF8=m The result is, that I cannot read special chars like the german umlauts Ã¤Ã¶Ã¼ when I mount a usb disk or something like that.
Comment 3 Dave Jones 2005-08-04 05:35:45 UTC
from man mount ... iocharset=value Character set to use for converting between 8 bit characters and 16 bit Unicode characters. The default is iso8859-1. Long filenames are stored on disk in Unicode format. The default the kernel uses is irrelevant if userspace is asking for something else. From the kernel help text about CONFIG_NLS_DEFAULT.. The default NLS used when mounting file system. Note, that this is the NLS used by your console, not the NLS used by a specific file system (if different) to store data (filenames) on a disk. Looks to me like if we want UTF-8 to be used always, we need those lines added to HAL.
Comment 4 Roland Wolters 2005-08-05 00:19:44 UTC
Is it wise to get these lines as standard, or are there reasons against having such standards?
Comment 5 Mariano Draghi 2005-11-12 04:36:56 UTC
I added these lines to /usr/share/hal/fdi/policy/10osvendor/10-storage-policy.fdi <!-- Use UTF-8 charset for vfat --> <match key="volume.fstype" string="vfat"> <merge key="volume.policy.mount_option.iocharset=utf8" type="bool">true</merge> </match> I'm not sure if this is the right place, but it works. I can also confirm that this worked out of the box with FC3, and I'm *almost* sure it worked with FC4 not so long ago.
Comment 6 Roland Wolters 2005-12-13 08:20:48 UTC
If I just add these lines in the second device section somewhere it doesn't work after restarting the hal daemon. I can't believe that Fedora Core, although working with utf8 internally, is working bad here... There is still the question why these lines are not standard for Fedora Core. What's about FC5? Is this problem supposed to be solved there? Especially when Fedora Core wants to support Chinese they should definitely do something around here!
Comment 7 Roland Wolters 2006-01-13 01:18:57 UTC
Created attachment 123145 [details] Patch to mount vfat with utf8 I hope that helps, but I wonder if it would be better to post this at freedesktop bugzilla.
Comment 8 Roland Wolters 2006-01-30 02:17:44 UTC
Sorry, forget the last post, that was not what we wanted (and it was uncommented, too, sorry about that). I've tested around a lot, and think now, that the easiest solution is what Mariano in comment 5 meant: to add a line which is checking for the key "volume.fstype", and to pick out these ones which has as string "vfat". Then we cann pass the mount options with merging the keys "volume.policy.mount_option.iocharset=utf8" and "volume.policy.mount_option.shortname=mixed" as true. All over all, we can add this almost to the ned of the file (short before </deviceinfo>), when we add <device>-tags to the part. It should like this: <!-- Use UTF-8 charset for vfat --> <device> <match key="volume.fstype" string="vfat"> <merge key="volume.policy.mount_option.iocharset=utf8" type="bool">true</merge> <merge key="volume.policy.mount_option.shortname=mixed" type="bool">true</merge> </match> </device> It works, tested with two different devices (iAudio player and partitioned external hard drive).
Comment 9 John (J5) Palmieri 2006-01-30 16:17:41 UTC
FC4 should already have the fix. I belive it was pushed last week. Rawhide will have it when upstream does its next release.
Comment 10 Roland Wolters 2006-01-30 22:25:40 UTC
Yes, I can confirm this patch, it works like a charm. Before I just had another test-package from another repo which haven't had included the patch, so I thought the problem still exists. So the bug can be closed. Solution: update the hal package to at least hal-0.5.2-2.fc4.1