Bug 162710 - usb sticks with FAT filesystem don't use utf8
usb sticks with FAT filesystem don't use utf8
Product: Fedora
Classification: Fedora
Component: hal (Show other bugs)
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: John (J5) Palmieri
Depends On:
  Show dependency treegraph
Reported: 2005-07-07 18:20 EDT by Roland Wolters
Modified: 2013-03-13 00:48 EDT (History)
3 users (show)

See Also:
Fixed In Version: 0.5.2-2.fc4.1
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2006-01-30 17:25:40 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
Patch to mount vfat with utf8 (2.75 KB, patch)
2006-01-12 20:18 EST, Roland Wolters
no flags Details | Diff

  None (edit)
Description Roland Wolters 2005-07-07 18:20:37 EDT
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"  
 <merge key="volume.policy.mount_option.shortname=mixed"  
to all FAT-lines  
in /usr/share/hal/fdi/policy/10osvendor/10-storage-policy.fdi , analogue to a  
concept given here:  
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):

How reproducible:

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-13 22:15:18 EDT
I misspelled the first line:  
<merge key="volume.policy.mount_option.iocharset=utf8"    
must be  
<merge key="volume.policy.mount_option.iocharset=utf8"    
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 17:30:21 EDT
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 
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 01:35:45 EDT
from man mount ...

    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-04 20:19:44 EDT
Is it wise to get these lines as standard, or are there reasons against having 
such standards? 
Comment 5 Mariano Draghi 2005-11-11 23:36:56 EST
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"

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 03:20:48 EST
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-12 20:18:57 EST
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-29 21:17:44 EST
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 -->  
    <match key="volume.fstype" string="vfat">  
      <merge key="volume.policy.mount_option.iocharset=utf8"  
      <merge key="volume.policy.mount_option.shortname=mixed"  
It works, tested with two different devices (iAudio player and partitioned 
external hard drive). 
Comment 9 John (J5) Palmieri 2006-01-30 11:17:41 EST
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 17:25:40 EST
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 

Note You need to log in before you can comment on or make changes to this bug.