device-automounter moved to kdereview

Hello,

I've moved device-automounter out of playground and into kdereview. After the
review, I hope for it to end up in kdebase/runtime/solid/. Then after that, I
hope to combine it with the solid-actions-kcm to let it handle other automatic
execution of actions when devices get attached.

device-automounter is a small kded plugin and kcm page that adds removable
media automounting to KDE. Its more than blindly automatic, since it has a
little bit more logic (further describe in the SETTINGS file) to make it
smarter than your average automounter, while still behaving without
configuration as a naive user would expect.

Everything passed krazy2all, with the exception of line 40 in
kded/DeviceAutomounter.cpp because I can't remember how to get krazy2 to
ignore the foreach checker. My rationale for that is that using
Solid::VolumeAccess::setup() requires a non-const Device, so two copy
constructors is cheaper than converting from a Device to a QString udi and
back. If I'm wrong, feel free to correct me/point and laugh.
--
Trever Fischer (tdfischer)
Fedora Ambassador, KDE Hacker
http://wm161.net
GPG: C40F2998 hkp://wwwkeys.pgp.net

[Albert Astals Cid-2]

A Diumenge, 9 d'agost de 2009, Trever Fischer va escriure:

> Hello,
>
> I've moved device-automounter out of playground and into kdereview. After
> the review, I hope for it to end up in kdebase/runtime/solid/. Then after
> that, I hope to combine it with the solid-actions-kcm to let it handle
> other automatic execution of actions when devices get attached.
>
> device-automounter is a small kded plugin and kcm page that adds removable
> media automounting to KDE. Its more than blindly automatic, since it has a
> little bit more logic (further describe in the SETTINGS file) to make it
> smarter than your average automounter, while still behaving without
> configuration as a naive user would expect.
>
> Everything passed krazy2all, with the exception of line 40 in
> kded/DeviceAutomounter.cpp because I can't remember how to get krazy2 to
> ignore the foreach checker. My rationale for that is that using
> Solid::VolumeAccess::setup() requires a non-const Device, so two copy
> constructors is cheaper than converting from a Device to a QString udi and
> back. If I'm wrong, feel free to correct me/point and laugh.

The kcm Name column is showing the udi and that's ugly, i think using
description() would make a betted default.

Albert

[Albert Astals Cid-2]

A Diumenge, 9 d'agost de 2009, Trever Fischer va escriure:

> Hello,
>
> I've moved device-automounter out of playground and into kdereview. After
> the review, I hope for it to end up in kdebase/runtime/solid/. Then after
> that, I hope to combine it with the solid-actions-kcm to let it handle
> other automatic execution of actions when devices get attached.
>
> device-automounter is a small kded plugin and kcm page that adds removable
> media automounting to KDE. Its more than blindly automatic, since it has a
> little bit more logic (further describe in the SETTINGS file) to make it
> smarter than your average automounter, while still behaving without
> configuration as a naive user would expect.
>
> Everything passed krazy2all, with the exception of line 40 in
> kded/DeviceAutomounter.cpp because I can't remember how to get krazy2 to
> ignore the foreach checker. My rationale for that is that using
> Solid::VolumeAccess::setup() requires a non-const Device, so two copy
> constructors is cheaper than converting from a Device to a QString udi and
> back. If I'm wrong, feel free to correct me/point and laugh.

Also it seems you only automount Solid::StorageVolume devices, so i think it
would make sense to only show this kind of devices in the kcm page.

Albert

On Sunday 09 August 2009 4:43:43 pm Albert Astals Cid wrote:

> A Diumenge, 9 d'agost de 2009, Trever Fischer va escriure:
> > Hello,
> >
> > I've moved device-automounter out of playground and into kdereview. After
> > the review, I hope for it to end up in kdebase/runtime/solid/. Then after
> > that, I hope to combine it with the solid-actions-kcm to let it handle
> > other automatic execution of actions when devices get attached.
> >
> > device-automounter is a small kded plugin and kcm page that adds
> > removable media automounting to KDE. Its more than blindly automatic,
> > since it has a little bit more logic (further describe in the SETTINGS
> > file) to make it smarter than your average automounter, while still
> > behaving without configuration as a naive user would expect.
> >
> > Everything passed krazy2all, with the exception of line 40 in
> > kded/DeviceAutomounter.cpp because I can't remember how to get krazy2 to
> > ignore the foreach checker. My rationale for that is that using
> > Solid::VolumeAccess::setup() requires a non-const Device, so two copy
> > constructors is cheaper than converting from a Device to a QString udi
> > and back. If I'm wrong, feel free to correct me/point and laugh.
>
> The kcm Name column is showing the udi and that's ugly, i think using
> description() would make a betted default.
>
> Albert
>

In order to retrieve the UDI, the device must be present, yes? The KCM gets

its list of devices from the configuration file, and not solid. I could easily
set it to show the human-friendly name if solid says the device is attached,
but the only way I see that happening for devices not attached is to store
that bit of data into the config file, which seems like an ugly hack to me.
--
Trever Fischer (tdfischer)
Fedora Ambassador, KDE Hacker
http://wm161.net
GPG: C40F2998 hkp://wwwkeys.pgp.net

[Albert Astals Cid-2]

A Diumenge, 9 d'agost de 2009, Trever Fischer va escriure:

> On Sunday 09 August 2009 4:43:43 pm Albert Astals Cid wrote:
> > A Diumenge, 9 d'agost de 2009, Trever Fischer va escriure:
> > > Hello,
> > >
> > > I've moved device-automounter out of playground and into kdereview.
> > > After the review, I hope for it to end up in kdebase/runtime/solid/.
> > > Then after that, I hope to combine it with the solid-actions-kcm to let
> > > it handle other automatic execution of actions when devices get
> > > attached.
> > >
> > > device-automounter is a small kded plugin and kcm page that adds
> > > removable media automounting to KDE. Its more than blindly automatic,
> > > since it has a little bit more logic (further describe in the SETTINGS
> > > file) to make it smarter than your average automounter, while still
> > > behaving without configuration as a naive user would expect.
> > >
> > > Everything passed krazy2all, with the exception of line 40 in
> > > kded/DeviceAutomounter.cpp because I can't remember how to get krazy2
> > > to ignore the foreach checker. My rationale for that is that using
> > > Solid::VolumeAccess::setup() requires a non-const Device, so two copy
> > > constructors is cheaper than converting from a Device to a QString udi
> > > and back. If I'm wrong, feel free to correct me/point and laugh.
> >
> > The kcm Name column is showing the udi and that's ugly, i think using
> > description() would make a betted default.
> >
> > Albert
>
> In order to retrieve the UDI, the device must be present, yes? The KCM gets
> its list of devices from the configuration file, and not solid. I could
> easily set it to show the human-friendly name if solid says the device is
> attached, but the only way I see that happening for devices not attached is
> to store that bit of data into the config file, which seems like an ugly
> hack to me.

I prefer what you call a ugly hack to showing something like

'/org/freedesktop/Hal/devices/usb_device_13fe_1d00_07760EA20082'
'/org/freedesktop/Hal/devices/usb_device_13fe_1d00_07760EA20082_if0'
'/org/freedesktop/Hal/devices/volume_uuid_0036_A680'
'/org/freedesktop/Hal/devices/storage_serial__USB_DISK_2_0_07760EA20082_0_0'

Because i'm sure my father won't recognise any as the usb key i just inserted.

On a separate note, you should try to fix sizing of the view, the "Always
Automount" column is BIG when it's the Name column that should be the one with
most space available.

Albert

Am Montag, 10. August 2009 00:10:01 schrieb Albert Astals Cid:
> I prefer what you call a ugly hack to showing something like
>
> '/org/freedesktop/Hal/devices/usb_device_13fe_1d00_07760EA20082'
> '/org/freedesktop/Hal/devices/usb_device_13fe_1d00_07760EA20082_if0'
> '/org/freedesktop/Hal/devices/volume_uuid_0036_A680'
>
'/org/freedesktop/Hal/devices/storage_serial__USB_DISK_2_0_07760EA20082_0_0
>'
>
> Because i'm sure my father won't recognise any as the usb key i just
> inserted.

I fell into that trap too. :)

The thing is that normal users are not supposed to work with that list. For
normal users it works like this:

1. Plug in the external device and mount it with dolphin or similar. The
device is now known.
2. Plug it in again and it will be mounted automatically

The list is only if you want to override any of the settings for a certain
device.

Maybe that list could be hidden into an advanced dialogue.

Sven

On Monday 10 August 2009 00:31:20 Sven Burmeister wrote:

> Am Montag, 10. August 2009 00:10:01 schrieb Albert Astals Cid:
> > I prefer what you call a ugly hack to showing something like
> >
> > '/org/freedesktop/Hal/devices/usb_device_13fe_1d00_07760EA20082'
> > '/org/freedesktop/Hal/devices/usb_device_13fe_1d00_07760EA20082_if0'
> > '/org/freedesktop/Hal/devices/volume_uuid_0036_A680'
>
> '/org/freedesktop/Hal/devices/storage_serial__USB_DISK_2_0_07760EA20082_0_0
>
> >'
> >
> > Because i'm sure my father won't recognise any as the usb key i just
> > inserted.
>
> I fell into that trap too. :)
>
> The thing is that normal users are not supposed to work with that list. For
> normal users it works like this:
>
> 1. Plug in the external device and mount it with dolphin or similar. The
> device is now known.
> 2. Plug it in again and it will be mounted automatically
>
> The list is only if you want to override any of the settings for a certain
> device.
>
> Maybe that list could be hidden into an advanced dialogue.

Even then, the UIDs are totally unreadable. Advanced dialogues need to be human-
readable as well :)
--
sebas

http://www.kde.org | http://vizZzion.org | GPG Key ID: 9119 0EF9

On Sunday 9 August 2009 21:34:45 Trever Fischer wrote:
> I've moved device-automounter out of playground and into kdereview. After
> the review, I hope for it to end up in kdebase/runtime/solid/.

Shouldn't be a problem I guess if we can agree on a few changes. :-)

> Then after that, I hope to combine it with the solid-actions-kcm to let
> it handle other automatic execution of actions when devices get attached.

Well, at least for the configuration parts that looks like the way to go. All
this stuff should be presented at one place (from the user pov). You'll
probably have to discuss with Ben Cooksley for that who is in charge of the
action kcm.

BTW, most of the people working on the hardware related topics are on kde-
hardware-devel so you probably want to register there.

> device-automounter is a small kded plugin and kcm page that adds removable
> media automounting to KDE. Its more than blindly automatic, since it has a
> little bit more logic (further describe in the SETTINGS file) to make it
> smarter than your average automounter, while still behaving without
> configuration as a naive user would expect.

I took a look at it and it's mostly doing it blindly albeit a few heuristics
as you mentionned. In any case that's the kind of stuff which can't work in a
multi-user environment, and it can also cause troubles when someone is
deleting/creating/formatting partitions. So here is my (short) list of
proposed changes.

1) bool shouldAutomount = deviceAutomount || (enabled && typeCondition &&
((automountKnown && known) || lastSeenMounted));
really has to become:
bool shouldAutomount = enabled && (... rest of the condition);

If I set automounting to disabled, I really want it disabled period. There
should not be some special exception to that.

2) AutomountEnabled should have false by default. So that means that (with the
previous change) automounting is completely shutdown by default. We can't
really afford having something doing automounting enabled by default for the
reasons I pointed out above (multi-user envs, formatting, etc.)

3) I agree with the other people who commented in this thread that using the
UDI in the GUI doesn't work, it's really confusing. Moreover some of the logic
there needs to be refined as for some reason when I plugged my usb flash drive
(containing only one volume) I got 8 devices reported in the "Device
Overrides" list to always automount...
BTW a small nitpick on the KCM, the first column appears really tiny by
default here which makes the Name column unreadable.

> Everything passed krazy2all, with the exception of line 40 in
> kded/DeviceAutomounter.cpp because I can't remember how to get krazy2 to
> ignore the foreach checker. My rationale for that is that using
> Solid::VolumeAccess::setup() requires a non-const Device, so two copy
> constructors is cheaper than converting from a Device to a QString udi and
> back. If I'm wrong, feel free to correct me/point and laugh.

This you could solve by ditching the foreach construct in favor of a for loop
using C++ style iterators.

Regards.
--
Kévin 'ervin' Ottens, http://ervin.ipsquad.net
"Ni le maître sans disciple, Ni le disciple sans maître,
Ne font reculer l'ignorance."

Am Samstag, 15. August 2009 15:47:06 schrieb Kevin Ottens:

> On Sunday 9 August 2009 21:34:45 Trever Fischer wrote:
> > I've moved device-automounter out of playground and into kdereview. After
> > the review, I hope for it to end up in kdebase/runtime/solid/.
>
> Shouldn't be a problem I guess if we can agree on a few changes. :-)
>
> > Then after that, I hope to combine it with the solid-actions-kcm to let
> > it handle other automatic execution of actions when devices get attached.
>
> Well, at least for the configuration parts that looks like the way to go.
> All this stuff should be presented at one place (from the user pov). You'll
> probably have to discuss with Ben Cooksley for that who is in charge of the
> action kcm.
>
> BTW, most of the people working on the hardware related topics are on kde-
> hardware-devel so you probably want to register there.
>
> > device-automounter is a small kded plugin and kcm page that adds
> > removable media automounting to KDE. Its more than blindly automatic,
> > since it has a little bit more logic (further describe in the SETTINGS
> > file) to make it smarter than your average automounter, while still
> > behaving without configuration as a naive user would expect.
>
> I took a look at it and it's mostly doing it blindly albeit a few
> heuristics as you mentionned. In any case that's the kind of stuff which
> can't work in a multi-user environment, and it can also cause troubles when
> someone is deleting/creating/formatting partitions. So here is my (short)
> list of proposed changes.

About the former. How many computers that run KDE are real multi-user
environments, i.e. two or more users logged in at the same time?

> 2) AutomountEnabled should have false by default. So that means that (with
> the previous change) automounting is completely shutdown by default. We
> can't really afford having something doing automounting enabled by default
> for the reasons I pointed out above (multi-user envs, formatting, etc.)

I disagree at least in parts because I claim that newbies and "normal" users,
i.e. those with less knowledge should be the ones defaults aim at. So I'd
consider it harder for a newbie finding out why his device does not get
automounted then for an advanced user to disable it for real multi-user
environments, be it at home or even more so in an enterprise. About the
formatting and partition creating issues, what are these and how likely are
they to affect the normal user?

There should be some discussion about the actual cases where this can lead to
problems and better ways around them than just disabling this useful feature.

Sven

On Sunday 16 August 2009 17:04:01 you wrote:
> Am Samstag, 15. August 2009 15:47:06 schrieb Kevin Ottens:
> > I took a look at it and it's mostly doing it blindly albeit a few
> > heuristics as you mentionned. In any case that's the kind of stuff which
> > can't work in a multi-user environment, and it can also cause troubles
> > when someone is deleting/creating/formatting partitions. So here is my
> > (short) list of proposed changes.
>
> About the former. How many computers that run KDE are real multi-user
> environments, i.e. two or more users logged in at the same time?

Any system intended to be the server for thin clients for starters.  Also I
myself occasionally do this when my wife and I have to share the same
computer.

Regards,
 - Michael Pyne

On Sunday 16. August 2009 23:04:01 Sven Burmeister wrote:
> So I'd consider it harder for a newbie finding out why his device does not
> get automounted [...]

Don't mediums already get automounted when you access them (click in the file-
selector dialog, or in dolphin, etc.)? It does here, anywho, in KDE 4.3.0 on
Arch.

(What I really would like to see is some better feedback for when mediums
really are mounted, and better feedback while unmounting (maybe showing a
progressbar with data about how large the writeback buffer is, /proc/diskstats
maybe?).)

--
martin t. sandsmark

On Monday 17 August 2009 02:17:27 Michael Pyne wrote:

> On Sunday 16 August 2009 17:04:01 you wrote:
> > Am Samstag, 15. August 2009 15:47:06 schrieb Kevin Ottens:
> > > I took a look at it and it's mostly doing it blindly albeit a few
> > > heuristics as you mentionned. In any case that's the kind of stuff
> > > which can't work in a multi-user environment, and it can also cause
> > > troubles when someone is deleting/creating/formatting partitions. So
> > > here is my (short) list of proposed changes.
> >
> > About the former. How many computers that run KDE are real multi-user
> > environments, i.e. two or more users logged in at the same time?
>
> Any system intended to be the server for thin clients for starters.  Also I
> myself occasionally do this when my wife and I have to share the same
> computer.

Exactly, and that also includes the "Switch User" feature provided in our own
"Leave" menu. So any desktop we ship out there.

Regards.
--
Kévin 'ervin' Ottens, http://ervin.ipsquad.net
"Ni le maître sans disciple, Ni le disciple sans maître,
Ne font reculer l'ignorance."

On Sunday 16 August 2009 23:04:01 Sven Burmeister wrote:
> > 2) AutomountEnabled should have false by default. So that means that
> > (with the previous change) automounting is completely shutdown by
> > default. We can't really afford having something doing automounting
> > enabled by default for the reasons I pointed out above (multi-user envs,
> > formatting, etc.)
>
> I disagree at least in parts because I claim that newbies and "normal"
> users, i.e. those with less knowledge should be the ones defaults aim at.

Except that the use case for that are people with knowledge about what
mount/unmount is and want to access their device *now* from the console
without mounting first. Those obviously have enough knowledge to turn on the
automount and I don't plan to optimize for them (I'm one of those BTW).

For all the other users out there, the "mount on demand" as it is implemented
right now is enough. Anywhere you could access a device from the UI we mount
as soon as the user tries to make a first access attempt. It's not like they
need to know what mounting is...

> There should be some discussion about the actual cases where this can lead
> to problems and better ways around them than just disabling this useful
> feature.

There's on going work for that in the infrastructure below KDE (mainly on
Linux, and in the form of D-Bus services tied in system specifics facilities)
but it's still not ready yet, and I see nothing coming for some of the non-
Linux free platforms (I might be wrong there as I didn't check in a while).

Note that I'm not advocating to make it off by default until the end of times.
But right now it's calling for troubles to make it default.

Regards.
--
Kévin 'ervin' Ottens, http://ervin.ipsquad.net
"Ni le maître sans disciple, Ni le disciple sans maître,
Ne font reculer l'ignorance."

[Jos Poortvliet-4]

On Mon, Aug 17, 2009 at 8:09 AM, Kevin Ottens<ervin@...> wrote:

> On Sunday 16 August 2009 23:04:01 Sven Burmeister wrote:
>> > 2) AutomountEnabled should have false by default. So that means that
>> > (with the previous change) automounting is completely shutdown by
>> > default. We can't really afford having something doing automounting
>> > enabled by default for the reasons I pointed out above (multi-user envs,
>> > formatting, etc.)
>>
>> I disagree at least in parts because I claim that newbies and "normal"
>> users, i.e. those with less knowledge should be the ones defaults aim at.
>
> Except that the use case for that are people with knowledge about what
> mount/unmount is and want to access their device *now* from the console
> without mounting first. Those obviously have enough knowledge to turn on the
> automount and I don't plan to optimize for them (I'm one of those BTW).
>
> For all the other users out there, the "mount on demand" as it is implemented
> right now is enough. Anywhere you could access a device from the UI we mount
> as soon as the user tries to make a first access attempt. It's not like they
> need to know what mounting is...

You know this falls flat on it's face with session restore? I get
plenty of 'folder not accessible' messages every time I log in...

Maybe see what the usability ppl have to say about auto mounting or
not. I see how ppl who aren't very knowledgeable might need
automounting by default, and I see how it could hurt them...

>> There should be some discussion about the actual cases where this can lead
>> to problems and better ways around them than just disabling this useful
>> feature.
>
> There's on going work for that in the infrastructure below KDE (mainly on
> Linux, and in the form of D-Bus services tied in system specifics facilities)
> but it's still not ready yet, and I see nothing coming for some of the non-
> Linux free platforms (I might be wrong there as I didn't check in a while).
>
> Note that I'm not advocating to make it off by default until the end of times.
> But right now it's calling for troubles to make it default.
>
> Regards.
> --
> Kévin 'ervin' Ottens, http://ervin.ipsquad.net
> "Ni le maître sans disciple, Ni le disciple sans maître,
> Ne font reculer l'ignorance."
>

On Monday 17 August 2009 08:29:09 Jos Poortvliet wrote:
> On Mon, Aug 17, 2009 at 8:09 AM, Kevin Ottens<ervin@...> wrote:
> > For all the other users out there, the "mount on demand" as it is
> > implemented right now is enough. Anywhere you could access a device from
> > the UI we mount as soon as the user tries to make a first access attempt.
> > It's not like they need to know what mounting is...
>
> You know this falls flat on it's face with session restore? I get
> plenty of 'folder not accessible' messages every time I log in...

Different use case, and this one I'd have less problem to see it covered by
default (although it can break horribly as well for the same reasons that I
stated before). Note that it's not what it's about right now as the proposed
piece of software doesn't cover it.

> Maybe see what the usability ppl have to say about auto mounting or
> not. I see how ppl who aren't very knowledgeable might need
> automounting by default, and I see how it could hurt them...

Nothing to do with usability, it's about a bad trade off. Here it's about some
convenience for a few knowledgeable people which will in turn create harder to
debug problems because we can't implement the feature properly in the first
place (the underlying platform being lacking here).

Regards.
--
Kévin 'ervin' Ottens, http://ervin.ipsquad.net
"Ni le maître sans disciple, Ni le disciple sans maître,
Ne font reculer l'ignorance."

Am Montag, 17. August 2009 02:45:37 schrieb Martin T. Sandsmark:
> On Sunday 16. August 2009 23:04:01 Sven Burmeister wrote:
> > So I'd consider it harder for a newbie finding out why his device does
> > not get automounted [...]
>
> Don't mediums already get automounted when you access them (click in the
> file- selector dialog, or in dolphin, etc.)? It does here, anywho, in KDE
> 4.3.0 on Arch.

Clicking is not automounting. If you for example have your music or photos on
an external harddisk attached to your computer you have to mount it before
digikam or amarok can access the media. Nepomuk does als start to scan for
changed files right after KDE login, so if you are not quick enough, it might
consider the files gone.

> (What I really would like to see is some better feedback for when mediums
> really are mounted, and better feedback while unmounting (maybe showing a
> progressbar with data about how large the writeback buffer is,
> /proc/diskstats maybe?).)

That additional info might be useful indeed, yet has nothing to do with
automounting.

Sven

Am Montag, 17. August 2009 02:17:27 schrieb Michael Pyne:

> On Sunday 16 August 2009 17:04:01 you wrote:
> > Am Samstag, 15. August 2009 15:47:06 schrieb Kevin Ottens:
> > > I took a look at it and it's mostly doing it blindly albeit a few
> > > heuristics as you mentionned. In any case that's the kind of stuff
> > > which can't work in a multi-user environment, and it can also cause
> > > troubles when someone is deleting/creating/formatting partitions. So
> > > here is my (short) list of proposed changes.
> >
> > About the former. How many computers that run KDE are real multi-user
> > environments, i.e. two or more users logged in at the same time?
>
> Any system intended to be the server for thin clients for starters.  Also I
> myself occasionally do this when my wife and I have to share the same
> computer.

Which only tells me that I'm right. Servers have an admin, defaults are for
home users. I still claim that most of those home computers are not used as
real multi-user environments.

Sven

Am Montag, 17. August 2009 08:29:09 schrieb Jos Poortvliet:

> On Mon, Aug 17, 2009 at 8:09 AM, Kevin Ottens<ervin@...> wrote:
> > On Sunday 16 August 2009 23:04:01 Sven Burmeister wrote:
> >> > 2) AutomountEnabled should have false by default. So that means that
> >> > (with the previous change) automounting is completely shutdown by
> >> > default. We can't really afford having something doing automounting
> >> > enabled by default for the reasons I pointed out above (multi-user
> >> > envs, formatting, etc.)
> >>
> >> I disagree at least in parts because I claim that newbies and "normal"
> >> users, i.e. those with less knowledge should be the ones defaults aim
> >> at.
> >
> > Except that the use case for that are people with knowledge about what
> > mount/unmount is and want to access their device *now* from the console
> > without mounting first. Those obviously have enough knowledge to turn on
> > the automount and I don't plan to optimize for them (I'm one of those
> > BTW).
> >
> > For all the other users out there, the "mount on demand" as it is
> > implemented right now is enough. Anywhere you could access a device from
> > the UI we mount as soon as the user tries to make a first access attempt.
> > It's not like they need to know what mounting is...
>
> You know this falls flat on it's face with session restore? I get
> plenty of 'folder not accessible' messages every time I log in...
>
> Maybe see what the usability ppl have to say about auto mounting or
> not. I see how ppl who aren't very knowledgeable might need
> automounting by default, and I see how it could hurt them...

Other examples are that because photos and music collections are that big,
people might keep them on external harddrives, so if they start digikam, they
have to mount the external harddrive first. They might even need to close
amarok and digikam before logging out because otherwise they get errors during
the next login.

Those photos might even be indexed by nepomuk, i.e. scanned right after
logging in, or for a wallpaper slideshow etc.

Forcing them to add those disks to fstab is not really a solution and I bet
that most of those users would then run into trouble if they unplugged the hdd
once and wonder why the booting fails.

If multi-user environments are really that much trouble and not the exception
to the rule of computer usage, then the solution would be to enable KDE to
know when more than one user is logged in and suspend automounting only in
that case by default.

Sven

On Monday 17 August 2009 6:28:34 pm Sven Burmeister wrote:
> Which only tells me that I'm right. Servers have an admin, defaults are for
> home users. I still claim that most of those home computers are not used as
> real multi-user environments.

Sorry I have to chip in at this point.  IMHO *many* home computers are multi-
user systems.  I have 4 kids at home and not all of them have their own
computer (why should they?) - but they all have their own account on our
shared home computer.  And at any one time 2-3 of them are logged in.  Not
actively using it but logged in.

Currently this computer runs ubuntu and mounting of removable media is a
significant problem.  Most of the time it just doesn't work - crashing and
burning in a tangle of permissions issues.

Please don't ignore this use case.

Am Montag, 17. August 2009 08:09:11 schrieb Kevin Ottens:

> On Sunday 16 August 2009 23:04:01 Sven Burmeister wrote:
> > > 2) AutomountEnabled should have false by default. So that means that
> > > (with the previous change) automounting is completely shutdown by
> > > default. We can't really afford having something doing automounting
> > > enabled by default for the reasons I pointed out above (multi-user
> > > envs, formatting, etc.)
> >
> > I disagree at least in parts because I claim that newbies and "normal"
> > users, i.e. those with less knowledge should be the ones defaults aim at.
>
> Except that the use case for that are people with knowledge about what
> mount/unmount is and want to access their device *now* from the console
> without mounting first. Those obviously have enough knowledge to turn on
> the automount and I don't plan to optimize for them (I'm one of those BTW).
>
> For all the other users out there, the "mount on demand" as it is
> implemented right now is enough. Anywhere you could access a device from
> the UI we mount as soon as the user tries to make a first access attempt.
> It's not like they need to know what mounting is...

Are you sure? Did you search mailinglists or bugzilla for bugs/comments that
want automounting and wonder were it is gone or why Windows has it etc.? There
is for example https://bugs.kde.org/show_bug.cgi?id=175611 or
https://bugs.kde.org/show_bug.cgi?id=164053 or
https://bugzilla.novell.com/show_bug.cgi?id=434114. Have a look at the number
of users in CC, are they all experts and want automounting because of that or
are they rather normal users?

Automounting is not for people that know how to mount or what it is, its for
easy access to your devices without knowing how to mount it or the need to
wonder why Openoffice fails to save a document although the stick it should be
put on is already attached etc.

Sven