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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
