Bug#500540: kdebase: automounting vfat (partialy) case sensitive due to utf8 is plain wrong and dangerous
New version of pmount package was uploaded (and unblocked) recently. Sorry to say that, but upgrading to pmount 0.9.18 didn't fix the problem. [EMAIL PROTECTED]:~$ pmount -V 0.9.18 [EMAIL PROTECTED]:~$ dmesg | tail [64822.927396] sd 0:0:0:0: [sda] Write Protect is off [64822.927402] sd 0:0:0:0: [sda] Mode Sense: 68 00 00 08 [64822.927404] sd 0:0:0:0: [sda] Assuming drive cache: write through [64822.929250] sd 0:0:0:0: [sda] 1941441 4096-byte hardware sectors (7952 MB) [64822.929889] sd 0:0:0:0: [sda] Write Protect is off [64822.929894] sd 0:0:0:0: [sda] Mode Sense: 68 00 00 08 [64822.929897] sd 0:0:0:0: [sda] Assuming drive cache: write through [64822.929900] sda: sda1 [64822.931560] sd 0:0:0:0: [sda] Attached SCSI removable disk [64827.615005] FAT: utf8 is not a recommended IO charset for FAT filesystems, filesystem will be case sensitive! [EMAIL PROTECTED]:~$ mount | grep ipod /dev/ipod on /media/IPOD type vfat (rw,nosuid,nodev,noatime,uhelper=hal,flush,uid=1000,shortname=lower) [EMAIL PROTECTED]:~$ pmount Printing mounted removable devices: /dev/ipod on /media/IPOD type vfat (rw,nosuid,nodev,noatime,uid=1000,fmask=0022,dmask=0022,codepage=cp437,iocharset=utf8,flush) To get a short help, run pmount -h [EMAIL PROTECTED]:~$ I still need to fix it everytime I attach a device by running: pumount /dev/ipod pmount -c iso8859-1 /dev/ipod /media/IPOD Then I get it mounted with the correct iocharset option AND the utf8 flag: [EMAIL PROTECTED]:~$ mount | grep ipod /dev/ipod on /media/IPOD type vfat (rw,noexec,nosuid,nodev,quiet,shortname=mixed,uid=1000,gid=1000,umask=077,fmask=0177,dmask=0077,utf8,iocharset=iso8859-1) [EMAIL PROTECTED]:~$ pmount Printing mounted removable devices: /dev/ipod on /media/IPOD type vfat (rw,nosuid,nodev,noexec,uid=1000,gid=1000,fmask=0177,dmask=0077,codepage=cp437,iocharset=iso8859-1,shortname=mixed,quiet,utf8) To get a short help, run pmount -h [EMAIL PROTECTED]:~$ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
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 againand 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]
Bug#379610: (bacula-wxconsole: restore mode dir parsing error)
Seems to have been be patched upstream ... see http://bugs.bacula.org/bug_view_advanced_page.php?bug_id=338 I guess there's no point in hoping this will get fixed for stable. So you can probably close this bug. cheers -h -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#379605: in file-selection mode bacula-console-wx issues .dir instead of dir
Package: bacula-console-wx Version: 1.38.9-10 Severity: important I'm trying to use the current testing/etch version of bacula-console-wx with a stable/sarge version of bacula-director. The bacula-director on sarge is version 1.36.2 (28 February 2005). So far everything seems to work. Only when I try to do a restore I can select the job but when I get to the file browser I can't get the directory contents listed. On the console tab I see this error message: $ .dir Illegal command. Enter done to exit. $ Looks like the older Sarge director doesn't understand the leading dot when in file selection mode. (It seems to work with all other commands when not in file selection mode) Entering restore's file selection mode manually (within bacula-console-wx) works and confirms my suspicion : When issuing dir I get my directory listing, when issuing .dir I get Illegal command. Enter done to exit.. I have not tested against a testing/etch bacula-director yet. cheers -henrik -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#379610: bacula-wxconsole: restore mode dir parsing error
Package: bacula-wxconsole Version: 1.36.2-2sarge1 In file-selection mode the parsing of dir output seems to assume fixed byte-position of filenames instead of word/field number. When switching to restore mode console shows the directory content like this. cwd is: / $ unmark * 218938 files unmarked. $ cd / cwd is: / $ dir drwxr-xr-x 21 root root4096 2006-02-09 15:54:43 / drwxr-xr-x 2 root root4096 2006-06-20 13:41:45 /bin/ drwxr-xr-x 3 root root4096 2006-03-20 10:59:21 /boot/ lrwxrwxrwx 1 root root 11 2005-12-30 16:29:29 /cdrom drwxr-xr-x 14 root root 13380 2006-07-24 08:02:41 /dev/ drwxr-xr-x 117 root root8192 2006-07-24 13:18:33 /etc/ drwxrwsr-x 5 root staff 4096 2006-03-14 22:12:27 /home/ drwxr-xr-x 2 root root4096 2005-12-30 16:30:14 /initrd/ lrwxrwxrwx 1 root root 28 2006-02-09 15:54:43 /initrd.img lrwxrwxrwx 1 root root 28 2006-01-02 22:03:25 /initrd.img.old drwxr-xr-x 15 root root8192 2006-06-20 13:54:51 /lib/ drwxr-xr-x 2 root root 49152 2005-12-30 16:29:16 /lost+found/ drwxr-xr-x 8 root root4096 2006-07-11 16:21:17 /media/ drwxr-xr-x 2 root root4096 2005-12-30 16:30:04 /mnt/ drwxr-xr-x 2 root root4096 2005-12-30 16:30:14 /opt/ drwxr-xr-x 24 root root4096 2006-07-06 16:30:13 /root/ drwxr-xr-x 2 root root4096 2006-06-20 13:54:06 /sbin/ drwxr-xr-x 2 root root4096 2005-12-30 16:30:14 /srv/ drwxr-xr-x 10 root root 0 2006-07-24 09:51:11 /sys/ drwxr-xr-x 13 root root4096 2006-01-19 16:58:08 /usr/ drwxr-xr-x 15 root root4096 2006-03-20 13:56:37 /var/ lrwxrwxrwx 1 root root 25 2006-02-09 15:54:43 /vmlinuz lrwxrwxrwx 1 root root 21 2006-02-09 15:54:43 /vmlinuz.old The link count of /etc/ breaks the nice formating and clicking on etc to expand it in the tree widget produces the following: $ cd /etc/ Invalid path given. cwd is: / $ dir drwxr-xr-x 21 root root4096 2006-02-09 15:54:43 / drwxr-xr-x 2 root root4096 2006-06-20 13:41:45 /bin/ drwxr-xr-x 3 root root4096 2006-03-20 10:59:21 /boot/ lrwxrwxrwx 1 root root 11 2005-12-30 16:29:29 /cdrom drwxr-xr-x 14 root root 13380 2006-07-24 08:02:41 /dev/ drwxr-xr-x 117 root root8192 2006-07-24 13:18:33 /etc/ drwxrwsr-x 5 root staff 4096 2006-03-14 22:12:27 /home/ drwxr-xr-x 2 root root4096 2005-12-30 16:30:14 /initrd/ lrwxrwxrwx 1 root root 28 2006-02-09 15:54:43 /initrd.img lrwxrwxrwx 1 root root 28 2006-01-02 22:03:25 /initrd.img.old drwxr-xr-x 15 root root8192 2006-06-20 13:54:51 /lib/ drwxr-xr-x 2 root root 49152 2005-12-30 16:29:16 /lost+found/ drwxr-xr-x 8 root root4096 2006-07-11 16:21:17 /media/ drwxr-xr-x 2 root root4096 2005-12-30 16:30:04 /mnt/ drwxr-xr-x 2 root root4096 2005-12-30 16:30:14 /opt/ drwxr-xr-x 24 root root4096 2006-07-06 16:30:13 /root/ drwxr-xr-x 2 root root4096 2006-06-20 13:54:06 /sbin/ drwxr-xr-x 2 root root4096 2005-12-30 16:30:14 /srv/ drwxr-xr-x 10 root root 0 2006-07-24 09:51:11 /sys/ drwxr-xr-x 13 root root4096 2006-01-19 16:58:08 /usr/ drwxr-xr-x 15 root root4096 2006-03-20 13:56:37 /var/ lrwxrwxrwx 1 root root 25 2006-02-09 15:54:43 /vmlinuz lrwxrwxrwx 1 root root 21 2006-02-09 15:54:43 /vmlinuz.old As you can see the cd command gets a wrong parameter. A further bug is that the output of a cd command doesn't get parsed and compared to the supplied parameter. Instead a simple dir command is issued and the output is presented as the content of /etc In the above example this means that I can infinetly recurse into the etc directory since I never realy leave / :-) The same problem probably gets triggered any (or a combination) of the following: - long usernames - long groupnames - big files Changing into other directories seems to work fine. cd /boot/ cwd is: /boot/ $ dir -rw-r--r-- 1 root root 542191 2005-12-30 16:01:58 /boot/System.map-2.4.27-2-386 -rw-r--r-- 1 root root 862526 2005-12-30 16:52:49 /boot/System.map-2.6.12-1-686 -rw-r--r-- 1 root root 659945 2006-01-03 13:56:19 /boot/System.map-2.6.14.5 -rw-r--r-- 1 root root 680667 2006-03-20 10:56:16 /boot/System.map-2.6.15-1-686 -rw-r--r-- 1 root root 44853 2005-12-30 16:01:58 /boot/config-2.4.27-2-386 -rw-r--r-- 1 root root 61109 2005-12-30 16:52:49 /boot/config-2.6.12-1-686 -rw-r--r-- 1 root root
