Bug#500540: automounting vfat as utf8
Hi Sune and thanks for taking up the issue.
On Mon, Oct 06, 2008 at 07:38:15PM +0200, Sune Vuorela wrote:
>
> KDE uses the information from hal to decide what options to use when
> mounting.
>
> On a vfat drive, hal gives the following:
> hal-get-property --udi '/org/freedesktop/Hal/devices/volume_uuid_64F8_AEF6' --
> key volume.mount.valid_options
> ro sync dirsync noatime nodiratime noexec quiet remount exec utf8 shortname=
> codepage= iocharset= umask= dmask= fmask= uid= flush
I'm with you there.
$ hal-get-property --udi '/org/freedesktop/Hal/devices/volume_uuid_8851_B65A' --key volume.mount.valid_options
ro sync dirsync noatime nodiratime noexec quiet remount exec utf8 shortname= codepage= iocharset= umask= dmask= fmask= uid= flush
Auto-mounting via kde results in this:
$ mount
...
/dev/sdc1 on /media/disk-1 type vfat (rw,nosuid,nodev,noatime,uhelper=hal,flush,uid=1000,utf8,shortname=lower)
$ pmount
...
/dev/sdc1 on /media/disk-1 type vfat (rw,nosuid,nodev,noatime,uid=1000,fmask=0022,dmask=0022,codepage=cp437,iocharset=utf8,utf8,flush)
And the kernel warning mentioned before.
So far we established the same facts. Now let's see if hal really is to
blame. We'll unmount the device and tell hal not to advertize the utf8
option.
$ pumount /dev/sdc1
$ hal-set-property --udi '/org/freedesktop/Hal/devices/volume_uuid_8851_B65A' --key volume.mount.valid_options --strlist-rem utf8
$ hal-get-property --udi '/org/freedesktop/Hal/devices/volume_uuid_8851_B65A' --key volume.mount.valid_options
ro sync dirsync noatime nodiratime noexec quiet remount exec shortname= codepage= iocharset= umask= dmask= fmask= uid= flushh
So now hal shouldn't tell anybody to mount this device with utf8.
And just to be on the safe side we'll make sure that we get the
default codepage and iocharset.
$ hal-set-property --udi '/org/freedesktop/Hal/devices/volume_uuid_8851_B65A' --key volume.mount.valid_options --strlist-rem "codepage="
$ hal-set-property --udi '/org/freedesktop/Hal/devices/volume_uuid_8851_B65A' --key volume.mount.valid_options --strlist-post "codepage=437"
$ hal-set-property --udi '/org/freedesktop/Hal/devices/volume_uuid_8851_B65A' --key volume.mount.valid_options --strlist-rem "iocharset="
$ hal-set-property --udi '/org/freedesktop/Hal/devices/volume_uuid_8851_B65A' --key volume.mount.valid_options --strlist-post "iocharset=iso8859-1"
So lets see what hal says now:
$ hal-get-property --udi '/org/freedesktop/Hal/devices/volume_uuid_8851_B65A' --key volume.mount.valid_options
ro sync dirsync noatime nodiratime noexec quiet remount exec shortname= umask= dmask= fmask= uid= flush codepage=437 iocharset=iso8859-1
That looks nice to me. Now I'll open "system:/media/" and click on
the device to get it auto-mounted and opened. (And before you ask,
no, I didn't unplug the device because that seems to reset all the
hal options set before.)
$ pmount
...
/dev/sdc1 on /media/disk-1 type vfat (rw,nosuid,nodev,noatime,uid=1000,fmask=0022,dmask=0022,codepage=cp437,iocharset=utf8,flush)
So, here we go again....and the kernel happily logs another:
[784167.941455] FAT: utf8 is not a recommended IO charset for FAT filesystems, filesystem will be case sensitive!
Looks like KDE doesn't realy care all that much about what hal says. At least
it seems to have left out the "utf8" flag option, so we know that we have
some effect. But overriding the iocharset is a bad idea.
> KDE can of course specialcase and don't use the utf8 option on fat filesystems,
> but I don't think it is the job for the frontend to know which options is safe
> and unsafe.
I agree. But it should care about the options that _are_ reported
by the backend. In this case it is not the "utf8" flag option but
the "iocharset=utf8" that causes the problems.
>From http://www.nslu2-linux.org/wiki/HowTo/MountFATFileSystems
> When the utf8 flag is specified along with iocharset the iocharset value
> only controls the character case handling - it has no effect on the encoding
> of the UNICODE characters as this will always use UTF-8.
>From that perspective hal is not to blame at all. Even if it reports
the "utf8" flag as a default mount option.
In short: The problem seems to be that kde doesn't care what hal reports
as an "iocharset".
BTW: I'm not quite sure if downgrading the bug to "important" is ok.
It seems to mess up file system structures and that should be examined
further. Maybe resulting in a separate bug that would carry on the "grave"
severity while this bug could be downgraded. Until then I consider a messed
up filesystem structure a grave bug.
cheers
-henrik
Reply to: