but you're aware that /usr/share can only be configured as root while KDE wants to provide user exchangable options, right?

> but you're aware that /usr/share can only be configured as root while KDE wants to provide user exchangable options, right?

Sure. I don't want to say that current implementation is completely bad and should be removed - I just spent whole Saturday trying to set up correct iocharset in /usr/share/hal using HAL specs and howtos... ;-) I was rather surprised when I saw the code in SVN. Maybe the better way would be let's call it "merge approach": mediamanger uses libhal_* calls to obtain properties it needs. These properties are then overwritten by the values from mediamanagerrc - i.e. if mediamanger has setting "foo=bar" (presumably, user has chosen something different for it's own account) - "bar" is used for "foo", otherwise we use value returned by libhal_volume_get_foo(). This will satisfy everybody (ok, ok, more people than current approach - at leat me): those willing to hack /usr/share/hal will do it and have fun, you (as a maintainer) wouldn't need to mirror every [new] setting from HAL in the mediamanagerrc. What do you think?

Btw I wasn't able to find the gui to set up mediamagerrc - where is it?

P.S. Thank you for setting up correct component for this bug. KDE bug filing wizard certainly left me lost :(

go to media:/ and press the right mouse button on a media to go for properties

> go to media:/ and press the right mouse button on a media to go for properties 
Ok, thank you for the explanation. But what's your opinion about "merged approach"?

Second problem is, there is no way to set defaults. So for every new device (let's say your friend USB stick) you have to first not mount it, then change options and then mount - esp. in the case of "your friend's USB stick" it leaves garbage behind that will likely be never used again. This is not entirely ergonomic and user-friendly ...

> Second problem is, there is no way to set defaults.
Absolutely. I wanted to implement something like this but taking into account the absence of spare time and the lack of interest from KDE developers to this bug I've abandonned the idea.

For now, I'm using hack to HAL mount scripts which set mount options I want.

> For now, I'm using hack to HAL mount scripts which set mount options I want.
How did you do this?

I tried the following, but it failed:

I wanted to set special mount-options for my USB-devices which the present KDE-MediaManager doesn't "know", i.e. "umask=0".


Therefore I've created /usr/share/hal/fdi/policy/20thirdparty/fat_mount.fdi

<?xml version="1.0" encoding="UTF-8"?> <!-- -*- xml -*- -->
<deviceinfo version="0.2">
<device>
  <match key="block.is_volume" bool="true">
    <match key="volume.fsusage" string="filesystem">
      <match key="volume.fstype" string="vfat">
        <merge key="volume.policy.mount_option.umask=0" type="bool">true</merge>
      </match>
    </match>
  </match>
</device>
</deviceinfo>

With old HAL (Version 0.4.*) the config-file above did the trick, because it was on fstab-sync to do mounting.

But now my SD-card will mounted as follows:
/dev/sdc1 on /mnt/CardReader_SD type vfat (rw,noexec,nosuid,nodev,noatime,uid=500,utf8,shortname=lower)


IMHO this is really a MUST that KDE-MediaManager can handle global mount-options defined in HAL-configs!!!
Like this you could define mount options for ALL external USB-devices with FAT-partition, NTFS-partition, etc.

In the moment you have to do the settings for every single storage-device, but only a handfull can be set-up!


Mount-options like "iocharset" and "codapage" are VERY important for correct displaying of characters!
"umask=0" i.e is NEEDED for NTFS-partitions, to be able to access them as normal user!

But all these are options KDE-MediaManager doesn't know!!!!!


My system:
Distro: Mandriva 2007
Kernel: 2.6.17
HAL-v.: 0.5.7.1
KDE-v: 3.5.4 

> How did you do this?
> ...
> Therefore I've created /usr/share/hal/fdi/policy/20thirdparty/fat_mount.fdi 
This will not work - that was why I've filled this bug.
HAL does read this file and put properties you've specified into right place in the tree - but it relies on third-party automounter to asks for these properties and then specify it when issuing mount call. I'd say it's design flaw of HAL but it's true - hal_*_mount method which can be easily found in the sources doesn't use directly the information you've provided in the .fdi. Instead, it expects mount app (a part of KDE in out case) to specify mount options (which, in theory, come from .fdi). However, KDE mounthelper doesn't honor the setting in .fdi - it use it's own (quite limited I'd say) configuration file instead. I've added moun options I need directly to the shell code in the hal-mount-something script which is part of HAL. It's quite ugly but it works. If you are interested - drop me an email please I'll send you scripts (however you may need to adjust something for your distro - I'm not using Mandriva)

Just for your information: some minutes ago I got an answer regarding this issue from David Zeuthen, developer of HAL:

> Hi,
> 
> You should take this issue up with the KDE developers and/or your
> distro. It works nicely for me Fedora Core 6 with gnome-mount, see 
>
> http://people.freedesktop.org/~david/gm-prop/gm-prop1.png
> http://people.freedesktop.org/~david/gm-prop/gm-prop2.png
> 
> for details. Btw, the volume.policy.* and storage.policy.* stuff is
> deprecated and KDE's media manager should not be using it.
>
>     David

Following hack in "/usr/share/hal/scripts/hal-system-storage-mount" did the trick for me:

# special options handling for certain filesystems
case "$MOUNTTYPE" in
    vfat)
   MOUNTOPTIONS="$MOUNTOPTIONS,codepage=850,iocharset=iso8859-15,fmask=177,dmask=022"
   ;;
    ntfs)
   MOUNTOPTIONS="$MOUNTOPTIONS,uid=$HAL_METHOD_INVOKED_BY_UID"
   ;;
esac

Bad luck for those who are already using HAL 0.5.8, because there the script mentioned above is not a script in plain text anymore, but a program in C.


So please think of a reimplementation of HAL in KDE!!!


I do understand the present implementation, that a normal user should not be aware of every single possible mount-option in a graphical user interface and therefore some options should be hidden.
But for the advanced user it MUST be possible to set ALL mount-options, no matter if it's done with a GUI or with tweaking a simple configuration-file of the DE.
Also it should be possible to set a standard-configuration for one type of device (i.e. one for FAT, one for NTFS, one for ext3, etc.).
Now I have to do the setup for every single device, if I want to have some things different, because the the setup done in KDE-MediaManager is ALWAYS related to the volume-ID of the device.

Please have a look on the implementation in "gnome-mount"!
http://people.freedesktop.org/~david/gm-prop/gm-prop1.png
http://people.freedesktop.org/~david/gm-prop/gm-prop2.png

It's highly configurable there: You can define the mount-options related to the used device, the volume, or the filessystem.

Created attachment 18543 [details]
Patch to implement the requested feature

This is the patch against latest SVN version of media kioslave which implements
much-requested "default options" feature. The usage scenario is (approximately)
as follows:

1. The user chooses default set of default mount options (applicable to all
devices) using "Advanced" tab in Control Center/Peripherals/Storage Media. If
the user doesn't touch anything there, the defaults currently hardcoded in HAL
backend will be used.
2. When the user plugs its media (say, USB stick), it is mounted with default
mount options. The user is able to influence this behavior by unchecking "Use
default mount options" checkbox in the Properties dialog/Mounting tab and
specifying the desired mount options applicable to this volume only.

An "upgrade scenario" was considered while designing the patch - i.e. the user
will not (hopefully) loose any of his settings when upgrading to this HAL
Backend.

Since volume.policy.* is declared obsolete now, all settings are stored in KDE
config files.

I kindly ask Stephen to review this patch and if he approves it I can commit
the code into KDE SVN.

Oops, it seems that Kevin, not coolo is currently maintaining media kioslave - sorry then. Kevin, please review the patch and if it's ok I'll commit it.

> If the user doesn't touch anything there, the defaults currently hardcoded in
> HAL backend will be used.

Question: is there anything hardcoded in HAL?? I thought it's completely on the Desktop-Environment now to handle all the mountoptions!
Just have a look at the present HAL-configurations files - it's only defined there what mount-option is allowed to be used, but it doesn't say which option to choose!

But it should be possible to define some default-options in KDE.
If this is not the desired method in some cases for some devices, it should be possible to define extra mount-options.

This is also the way gnome-mount does right now. Just have a look on the reply of David Zeuthen I received a while ago regarding this issue:

>> Is the setup done for EACH device/volume - or is it also possible to have a
>> standard-configuration for i.e. ALL FAT-formatted devices?
>
> Yes, see the gnome-mount man page
>
> http://cvs.gnome.org/viewcvs/*checkout*/gnome-mount/gnome-mount.1.in?rev=1.2
>
> Distros can then choose sane defaults based on what fs it is.
> ...
> ...
> The UI for gnome-mount needs some
> work though, it's not good UI to expose all options but advanced users
> should be able to use at least gconf-editor or gnome-mount on the
> command line to specify them.

> Question: is there anything hardcoded in HAL?? I thought it's completely on the Desktop-Environment now to handle all the mountoptions! 

Not HAL - HAL Backend, a part of KDE repsonsible for HAL interaction. It reads mount options from KDE config file (namely, mediamanagerrc) but, if this file does not exists/empty/has no group for the volume you are mounting (in the present state, i.e. without default mount options)/etc it resorts to some defaults, like Quiet = false, UTF-8 = true. These defaults are inherited by suggested patch.

> Not HAL - HAL Backend, a part of KDE repsonsible for HAL interaction.
Ah, o.k. Thank you for explainations.

Is it possible to change these default options of this KDE-HAL-backend, or are they hardcoded only in the present KDE-backend? I couldn't find out how it is done in the moment - do you have further informations about this?

Changing the default options would be IMHO very useful and desirable!


Perhaps this could also be done using some kind of DEFAULT-TAGS in mediamanagerrc?!?
=> default mount-options could be defined by editing mediamanagerrc as well as special mount-options for i.e. defined volume-id of a device. What do you think about this idea?


Nice to see that someone is working on this issue - thank you very much and keep on your work! Unfortunately I don't have coding-skills at all.

> Is it possible to change these default options of this KDE-HAL-backend, or are they hardcoded only in the present KDE-backend? I couldn't find out how it is done in the moment - do you have further informations about this? 

Ok, perhaps my comments are somewhat misleading. Here we go.
The whole idea of the patch is to have two set of mount options: default ones (which can be changed through Control Center and affect all volumes except those you especially marked by "Do not use default" checkbox in their - device Properties dialog) and per-volume (KDE 3.5.4-3.5.5 has only per-volume options). When you install the patch (perhaps with KDE 3.5.6 ;-)), default mount options set will be initialized with [currently] hard-coded values - after that you will be free to change them whoever you want. I, for instance, cleared "UTF8" checkbox in KDE Control Center - and now all my removable media are mounted without 'utf8' option, but if I'll want some of my USB stick to use utf8 (who knows why?) I'll just plug it, right click on it, switch to Mounting tab and clear "Use default mount options" checkbox - then check option "UTF-8".

Great! This would indeed massively improve the situation in KDE.

Perhaps the KDE-developers also think about NOT hardcoding the default mount-options anymore, but having a systemwide config-file instead?!?
Anyway, with your solution these hardcoded options would not be really necesary anymore, as you can easily define default values yourself.

What about options like fmask, dmask, umask, iocharset, codepage? Can they be choosen now with your patch?
The problem of the present solution right now is, that all these options are not known by KDE's MediaManager, yet - and therefore won't be choosen, even if I would define them in mediamanagerrc like this:

[/org/freedesktop/Hal/devices/volume_uuid_B0DB_424B]
"fmask=177"=true
"dmask=022"=true
"iocharset=iso8859-15"=true
"codepage=850"=true

Unfortunately something like this doesn't work - just because of the limited functionality of KDE's MediaManager. But this should be achieved, as well.

At this point I don't think that it's a must to set all mount-options via user-interface (there are lot of options out there and it would just bloat KDE's mount-UI), but of course it MUST be possible to set all of them somehow for the advanced user - i.e. via editing a configuration-file...

Created attachment 18547 [details]
KDE Control Center screenshot

The picture is worth 100 words and since my wording appears to be unclear I'm
attaching three screenshots to show how the patch looks.

First one is setting defaul mount options via KDE Control Center

Created attachment 18548 [details]
Setting custom mount options for my USB stick

Created attachment 18549 [details]
Applying default mount options to the same stick

> What about options like fmask, dmask, umask, iocharset, codepage? Can they be choosen now with your patch?
The problem of the present solution right now is, that all these options are not known by KDE's MediaManager, yet - and therefore won't be choosen...

Not yet. I'd like to commit the current patch before implementing new options. As a non-English speaker, I understand your needs :) (although I found out that iocharset is not necessary anymore - just clear UTF-8 checkbox and you are done. If it's not true, I guess UTF-8 checkbox could be transformed to Charset: combo box). The next step in the roadmap is to have some option to deal with *mask, but I haven't decided yet what is the best way to present it in a GUI. Any ideas?

I would also really appreciate if you post me (either here or to my e-mail) your "usage scenario" for these options - this would help me to identify how people use them. For instance, I need fmask/dmask support to clear executable attribute on mounted filesystems. You? :-) 

> As a non-English speaker, I understand your needs :) (although I found out
> that iocharset is not necessary anymore
For FAT-formatted drives, man mount says:
codepage=value 
 Sets the codepage for converting to shortname characters on FAT and VFAT filesystems. By default, codepage 437 is used
...
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.

So this means to me:
If you use long filenames these 2 values are not needed because Unicode will be used by default (I didn't know that FAT is such a modern file-system, either). ;-)
Only files with real 8.3 shortnames are affected.

I haven't tried out if all my assumtions are correct, because I only have long filenames on all my FAT-partitions, but I think that the need of being able to set codepage and iocharset is still valid. I will do a test now.


> The next step in the roadmap is to have some option to deal with *mask, but I
> haven't decided yet what is the best way to present it in a GUI. Any ideas?
Yes, of course. If it should be dealed with these options in a GUI:
1. One should be able to enable/disable the option via mouse-click, as it is already done right now.
2. There should be a field in addition where one can enter the extra information needed for the option.
3. If the option is disabled, the field will be greyed-out.

Just something like this:

[X] fmask [177]
            ^
       additional field to enter values for fmask

[X] iocharset [iso8859-15]
                  ^
       additional field to enter values for iocharset


Perhaps KDE should internaly check then, if the user has passed a valid code in the additional field?!?
I don't know if this is hard to do or not, but if it would not result in a crash I wouldn't mind if this step was left out.
Perhaps in worst case the mount-option only doesn't work as expected??? You'll have to find out what happens...

I don't think that a 2nd box for choosing values via mouse-click for fmask (and all the other mount-options which need some extra information) does make sense, because there would be plenty of posibilities for each of it.

What do you think?

Btw. your screen-shots look promising!

Just one thing: Like this, it's seems that it's still not possible to set the default options for a certain file-system, slot of a CardReader, etc.:
If you switch of UTF-encoding, you will do this for EVERY connected device, right? But perhaps this is not the desired method for all kind of devices.

Look at the screenies of the GNOME-UI:
http://people.freedesktop.org/~david/gm-prop/gm-prop1.png
http://people.freedesktop.org/~david/gm-prop/gm-prop2.png

It is separated into mount-options for:
* drive
* volume
And it seems that you can also enter mount-options for:
* filesystem

Not bad, I would say...


For me I've created a HAL-config-file for setting up the mount-points of my cardreader to
* /mnt/CardReader_SD  - for the SD-slot
* /mnt/CardReader_CF  - for the CF-slot
* and so on...

So the mount-points for my cardreader are independend of the volume-labels of the plugged storage cards now! (If you are interested how I've done this, I could show you)
If I could do something similar with KDE's mediamanager in the future without the need of hacking a HAL-configuration would really be a great feature!

Same with setting-up mount-options (independent from volume-ID!!!) for:
* FAT-partitions
* EXT3-partitions
* NTFS-partitions
* ... etc.


Just some thoughts for making things better in KDE...

> What do you think?
I think that simple drop-down box with 111, 112 ... 777 is out of the design goals - they are to present the user with simple and intuitive interface like "I don't want my files to be executable". And I don't understand how to do this without bloating up interface (see below).

> For FAT-formatted drives, man mount says: 
I know what man page says. But (at least for systems I own) your current system locale is used if you don't specify anything - that's what we need. Probably I've compiled the kernel with specific option - I don't remember

> If you switch of UTF-encoding, you will do this for EVERY connected device, right?

Nope, I just need to switch it off in the control center. If this option makes sense for the media you've inserted - your setting will be used. If not - ok, it will be just skipped (remember: "some options may not be applicable for certain device/filesystems"). There is no need to split default mount options between filesystems - Linux supports dozens of them. There is also no need to split between drives - _I_don_t_like_to_use_utf8_on_any_media_my_system_uses_8_bit_locale_, right? ;-) Why should I check in for CD-ROM, USB ports and card-reader? I just want to say: don't mount anything with utf8 enabled. That what Control Center module do.

> * FAT-partitions
> * EXT3-partitions
> * NTFS-partitions
> * ... etc. 
Indeed. Three+ pages for simple mount options - what next? Too many for the thing that should "just work", isn't it? ;-) I don't know many peaople would like to tweak FAT preferences - most of them will just need to plug an USB Flash and open a file without seeing garbage instead of your native alphabet. My take is set of options should be kept as simple as possible.

> I think that simple drop-down box with 111, 112 ... 777 is out of the design goals
This is also what I'm thinking - maybe you you got me wrong.

> I know what man page says. But (at least for systems I own) your current system locale is used if you don't specify anything
I've made a test now: Windows XP is smart enough to automaticly store the filename  in the uncode-encoded longfile-format - even if the filename has a standard length of 8.3 - this is why usualy there are no problems with encoding.

BUT - if you use a real MS-DOS system it's different!!!

Just try the following, if you have MS-Windows:
* Make a boot-disk with the fomrmat-program
In the new created AUTOEXEC.BAT there will be the following lines added:

mode con codepage prepare=((850) ega.cpi)
mode con codepage select=850

If you start your system with this boot-disk and do something like:
mkdir spaß
mkdir färben
mkdir mörser

If you type in "dir" everything seems to be fine, you can see all these characters correctly displayed.
This is not the case under Linux - there you have encoding-issuse!! As there was no additional longfile-format stored in unicode in real DOS-mode.

> There is no need to split default mount options between filesystems
> ...
> There is also no need to split between drives
> ...
> Indeed. Three+ pages for simple mount options - what next?
Mmmhh - gnome-mount already shows this way and it would be possible there to setup the mountpoints for a cardreader via UI as explained above.
But maybe you are right - in a user-interface this could be overkill.

As I said somewhere above: I don't think that it's a must to set all mount-options via user-interface, but of course it MUST be possible to set all of them somehow for the advanced user in the why he likes - i.e. via editing a configuration-file.

There are already sections in mediamanagerrc like:
[/org/freedesktop/Hal/devices/storage_serial_Generic_IC1210_MMC_SD_0000001]
automount=false/true

which already implement the ability of setting options related to the drive!

If it is possible to set the mount-point / mount-option by simply dropping a line into this drive-section instead of the volume-ID-section - this is all I want!

>> I think that simple drop-down box with 111, 112 ... 777 is out of the design goals
>This is also what I'm thinking - maybe you you got me wrong.

If you meant text edit field, this wouldn't serve well either - numeric permission mask is not used in other parts of KDE. Only checkboxes are - but they will make interface unnecessary bloat.

> I've made a test now: Windows XP is smart enough to automaticly store the filename  in the uncode-encoded longfile-format - even if the filename has a standard length of 8.3 - this is why usualy there are no problems with encoding.

I haven't seen anything except XP/2000 for ages. Probably this is an issue with earlier filesystems - anyway, having combo box with encodings instead of plain UTF-8/non-UTF-8 wouldn't hurt.

> Mmmhh - gnome-mount already shows this way and it would be possible there to setup the mountpoints for a cardreader via UI as explained above. 
Sure - I've seen gnome-mount. It's ok when you have card-reader, but if you just have plain old USB stick? The drive for the stick is stick itself and you end up where you've started - you need to specify your options on per-device basis, not globally. Filesystem options improves the situation but until someone says: "I'm using UFS on my CD-R, please add this tab". Not to mention options will be identical on many tabs... Gnome guys are somewhat lucky- they does not produce user-friendly option names - just a field where you can enter mount options. Btw, this is nice idea for "expert options" you've mentioned earlier.

> If you meant text edit field, this wouldn't serve well either - numeric
>  permission mask is not used in other parts of KDE.
Yes, I thought of a text edit field. In this case it's quicker and easier to type-in some numbers between 000..777 than choosing the right combination in a huge list via mouse - isn't it?
Where is your problem with this? Better this way then no way I'd say.

> but if you just have plain old USB stick? The drive for the stick is stick itself
So what? You don't need to set options for the device, then. It should be a possible option, not a  must. Some tabs for drive-, volume- and filesystem-options IMHO won't hurt in KDE.

> having combo box with encodings instead of plain UTF-8/non-UTF-8 wouldn't hurt
Good idea!


Maybe it would also be a good idea to devide the mount-option stuff into beginner- and expert-options...?!?!


> Gnome guys are somewhat lucky
Ideed they are - you can set almost everything in that GUI, but the way they are doing things of course is less userfriendly for a beginner. But finally this is not really the point:

The big issue is that while gnome-mount knows all mount-options, with KDE it's impossible to mount NTFS-partitions or to set *mask's. I wouldn't even mind to edit some configuration files instead of using a GUI in KDE - if it worked, which it currently doesn't.

> Yes, I thought of a text edit field. In this case it's quicker and easier to type-in some numbers between 000..777 than choosing the right combination in a huge list via mouse - isn't it?


The would be no problem with it, if the whole mount manager interface was using "here you have a GUI fields to set standard mount(1) options paradigm". Unfortunately, it's not - it's all about presenting user-friendly way to say how to handle the volume/device. And asking the user to enter octal permissions is certainly nor that friendly - i.e. it fails out of the interface paradigm. 

>Where is your problem with this? Better this way then no way I'd say. 
Nope - the Qt/KDE ideology is to have not "just something to work" but "a thing that work in a right way". And that right way has yet to be found :-)

>So what? You don't need to set options for the device, then. It should be a possible option, not a  must. Some tabs for drive-, volume- and filesystem-options IMHO won't hurt in KDE.

Once again. With USB stick (the most common storage media so far), drive is the stick itself, volume is partition on that stick, filesystem is FS used on that partition. The question is: "I want all my USB sticks to mount automatically - how do I do this". There is _no_ place in your/Gnome scheme where I can set up options that affects *all* USB sticks. "Okay, use extra (forth!) defaults tab for that", one says. That's right but 90% of that tab would be identical for Device/Volume tab - same checkboxes, same values. So why should one keep those redundant tabs?

> The big issue is that while gnome-mount knows all mount-options, with KDE it's impossible to mount NTFS-partitions
That's simply *not* true. Nothing prevents you from mounting NTFS or setting NTFS options via default options in Control Center. Read again: default mount options affect ALL media. If some option is applicable for NTFS voulme, it will be used. If it's not applicable, it will be dropped while mounting NTFS volume. There is absolutely no need to specify to which filesytem does belong this or that options - the user should just supply the value for the option and it's up to the system to decide whether it is applicable to the FS he currently mounts. Example: the user needs to say: "I need to convert all my filenames to ISO-8859-15, since my system uses this locale, period". It's up to KDE to translate this to the appropriate mount option for NTFS, FAT, Ext3, IOS9660 etc.

The only problem with this approach is when one option is supported for many FS and you need to have them different - but I can't imagine how this could be used.

So, basically, we are thinking in different domains. You are speaking about mount options (as specified by mount(1) manpage) and insist on one-to-one relationship between them and GUI elements. The currently implemented approach is about meaningful options like "Read only", "Synchronize every write operation", "Do not update timestamps on access", "Mount automatically", "Use charset XXX to convert volumes" - something that is not directly related to mount options. I.e. automount does not have direct mount(1) equivalent at all.

> That's simply *not* true. Nothing prevents you from mounting NTFS or setting
> NTFS options via default options in Control Center.
Yes, there is something that prevets me from doing that!!! Just look at the following screenshots of my system - Mandriva 2007 with KDE 3.5.4:
1. I can't set default options in KDE right now, like it's shows in comment #18
2. I can set "mount as user" for FAT-partitions
3. But I CAN'T set "mount as user" for NTFS-partitions

I don't know what system you are currently using, but for me unfortunately it is that way, as you can see!!

Now tell me how I should mount NTFS-partitions without tweaking the file /usr/share/hal/scripts/hal-system-storage-mount

Created attachment 18602 [details]
KDE Control Center

Created attachment 18603 [details]
possible mount-options for NTFS

Created attachment 18604 [details]
possible mount-options for FAT

1. Calm down
2. Read the thread ONCE AGAIN: we are discussing THE PATCH, not Mandriva, not SUSE, not *ANYTHING ELSE*. If you don't have the patch installed - you are out.
3. With patch installed, you can check the box 'Mount as user' in KDE Control Center.

Got it?

And the whole reason of discussing the patch is to see if it's ok to commit it to KDE SVN so you can get in in your's distro packages.

Hello guys.

I have some suggestions on this bug:
Of course congure everythink from GUI is great. But why not to use HAL mount_options from "volume.policy.mount_option.*". HAL's flexibility is great as I can see, and for admins it's much easier to setup serverwide configuration via HAL.

So I suggest the following algorithm:
mediamanager reads valid options (as it does nowerdays)
then it setup possible options (as it does nowerdays)
then it remove options which 
    volume.policy.mount_option.<option>=false
and adds options which
    volume.policy.mount_option.<option>=true

I'm going to write such patch now, but if you have any suggestions, you can write them.

> But why not to use HAL mount_options from "volume.policy.mount_option.*".
Please read comment #9 and you'll know that this won't work anymore, as these options are deprecated in newer HAL-versions.

Don't waste your time! I've already tried it - setting options like this doesn't have an effect on mounting the devices anymore.

=\ It's dificult to understand all that stuff, cause HAL documentation sucks. I wrote to hal mailing lists some questions, may be they will reply.

> I'm going to write such patch now, but if you have any suggestions, you can write them.

As MaxiPunkt says it's useless - mount_options.* are deprecated in HAL. No, I also don't have an idea, why. :(

Concerning my patch - I got a response from Kevin Ottens. He does not allow me to commit it because KDE 3.5.x is somewhat frozen - no feature enhancements are allowed unless they are "already widely used in a distribution" (yeah, I don't know how coloo's HAL backend was committed then back in August, but...). The patch I proposed is considered to be a feature since it introduces new user-visible strings. There were also some complains on the code itself - they could be easily fixed but as far I have no idea how to fix this bug WITHOUT introducing ANY user-visible string (yes, one can revert to editing KDE config files but what's the reason for using desktop environment then?), I've dropped an idea.

Well, I wrote patch cause I need it.
It use HAL settings (volume.policy.mount_option.*) (depricated, but at least it allow me to setup iocharset) if they are exists.
More info (in Russian): http://gq.net.ru/2007/01/25/kde-mountoptions-patch/

Created attachment 19441 [details]
Patch to force using HAL mountoptions if they exists

I confirm this bug.

It makes device automount feature useless with KDE

I use koi8-r locale, so I need to mount cdroms, ntfs and vfat with iocharset=koi8-r.
Unfortunately, this is not possible. KDE gives me choice between unicode and no unicode, and not respects hal mount_option's.

It should automatically suggest 'iocharset=<locale codepage>' in 'no unicode' mode, because mounting everything in latin-1 encoding is just plain stupid in that case.

I know 8-bit encodings are considered deprecated, but most russians I know prefer 8-bit locales, for diverse reasons.

*** This bug has been confirmed by popular vote. ***

For developers... 
When you will correct this bug - pay attention that in FreeBSD, for "vfat" there are no options of assembling - "iocharset", and "codepage" - instead of them, options "-L", "-D" or "-W" are used.


In ports FreeBSD, there is a patch solving this problem for file system "iso9660" and "udf":
http://www.freebsd.org/cgi/cvsweb.cgi/ports/x11/kdebase3/files/extrapatch-kioslave_media_mediamanager-halbackend.cpp.diff?r1=1.2;r2=1.3;f=h
but it does not solve a problem with other types of file systems, such as msdosfs.

Created attachment 20368 [details]
Patch For FreeBSD

Patch for FreeBSD, based on patch for Linux, above...

copy patch in /usr/ports/x11/kdebase3/files/
and rebuild kdebase3.
create file:
====================================
more /usr/local/etc/hal/fdi/policy/20-flash.fdi
<?xml version="1.0" encoding="UTF-8"?> <!-- -*- SGML -*- -->
 <deviceinfo version="0.2">
  <device>
<match key="volume.fstype" string="vfat">
        <merge key="volume.policy.mount_option.-L=ru_RU.KOI8-R" type="bool">true</merge>
        <merge key="volume.policy.mount_option.-D=CP866" type="bool">true</merge>
</match>
  </device>
 </deviceinfo>
==================================
and restart hald

This bug has another side effect. While a couple of users are running KDE sessions simultaneously, only one of them will  be able to manipulate files on a removable media.

I tried the following:
1. Open first session by user1 on vt7
2. Open second session by user2 on vt8
3. Switched back to vt7, inserted an USB flash drive.
4. Tried to remove some files from flash - that failed because the drive was mounted and all files on it were owned by user2.

Spent some hours trying to set a different umask (granting all users write access not regarding to who mounted the media) then found this thread...

It's probably make sense to mount removable media by currently active user, not by user who opened its session latter.

Sorry for my English, I tried to explain as clearly as I can :)

This bug has been here for some time, and it would be nice to solve it.

A workaround could be the solution #41 by Alexander, unfortunately that option is deprecated and some of the functions used in the patch doesn't even appear in the HAL documentation.

So I have 2 ideas so far. The first one would be fixing the mediamanager mounter so it takes the current system locale somehow and pass that parameter to the actual mounter using iocharset=<local charset>

This would relief this bug but it wouldn't solve it for real.

Another idea would be to add more mounting options in the media dialog under something like an "Advanced..." button. There you could include all possible options that hal can handle (add a text box for those started with '=') this solution would add support for things like umask and so on.

I could look into the code and with some help maybe we(I) could fix the bug provided that someone accepts the patch and committed it into svn.

What do you think?

Look i.e. at comment #10 and #27:

As there are views on userfriendliness vs. providing all mountoptions in a GUI, I would propose the following:

1. step: make KDE-MediaManager know ALL POSSIBLE mountoptions
2. step: make KDE-MediaManager to handle configurations for filesystem-types too (one for FAT, i.e.), not only related to a device (vol_UUID)
3. step: Implement options which should be selectable in a GUI


If steps 1 & 2 are made, one could already tweak KDE-MediaManager in a way one personaly likes most. I wouldn't mind if I had to edit mediamanagerrc-file manually to get some special things done, which won't be used by a beginner.


As there are different views on "step 3" what should be implemented and what not, this one could the most painful one. As long as "step 3" will be discussed only, there is no proceeding at all.

In reply to coments #48 and #49.

Honestly, UI'm not really sure this bug will be ever fixed in KDE3. I've contacted Kevin Ottens back in 2006 and he said the fix is inappropriate since it introduce new user-visible strings (i.e. changes the UI) and thus is rather not a bugfix but a new feature, which is not permitted for 3.5 codebase (it's frozen now). So I've abandoned all the attempts to push the patch upstream and use combination of Alexander's patch and my own code.

My apologize to Kevin if I've misunderstood him - but to the best of my knowledge the situation is as described.

You're talking about fixing/not fixing it in KDE3.

What efforts have been made in KDE4 regarding this bug, already? I assume it's the same situation as for KDE3...

This bug is open for 1,5 years now, KDE4 is already out, and up to now there were only discussions how to change UI "the right way", but noone has started to make MediaManager knowing more mountoptions, regardless which of them finally will be implemented in a GUI.


As I already wrote, I wouldn't mind if meanwhile I had to edit configuration-files to get things done in a way I like. In the moment I can't even do this, neither in KDE3 nor in KDE4.   :(

Did something change regarding to this bug in KDE 4.1?

yes. see bug 161673

kio media is gone in KDE4.