[proposal] VolumeAutomount and VolumeAutoUnmount notifications

[David Zeuthen]

Hi,

Sorry for the lag,

On Thu, 2004-09-23 at 18:17 +0100, Luke Kenneth Casson Leighton wrote:
> hi,
> 
> would it be okay to create the above notify messages for use with KVM?
> 
> the behaviour of KVM (and GDM) would need to be rather different from
> VolumeMount than from VolumeAutoMount.
> 
> reason: you _do not_ want KVM or GDM to run the "mount" command on an
> automounted point, which is what they would do.
> 
> rather, these programs should just "trust" HAL that autofs has
> "got it covered" :)
>

I'm not sure this is a good idea; I actually think it's very desirable
to do the mount in the actual desktop session instead of letting some
root process mount it. OK, mount(1) is setuid root, but it manages to
get the permissions right, so e.g. my USB stick is only writable for uid
500.

Another reason is that g-v-m and k-v-m I suppose respects the users
preferences (e.g. only automount USB sticks and not optical discs) and
these are stored in gconf or the KDE equivalent.

Sometimes we also want explicitly not to mount something - for instance,
g-v-m now refuses to mount an optical disc if another process is holding
a lock on the hal device object representing the optical drive. This is
useful as a cd-recording application can take this lock and a non-blank
CD-RW won't be mounted (which is the desired effect as the cd-recording
app is asking the user to insert a disc to write that .iso file to).

> the alternative is for KVM and GDM to read /etc/auto.hal - which might
> in fact at some point turn into a shell script rather than be a flat
> configuration file - which is therefore neither desirable nor maybe
> in the future even possible.
> 
> also, i don't believe it's a good idea for KVM or GDM to actually be
> doing the mounts and unmounts themselves: as i mentioned before, it
> leads to OS-specific code in KDE and Gnome [that HAL is supposed to
> alleviate].
> 

Yeah. I just mailed to the hal mailing list about the libhal-storage
library which is basically a C wrapper of the hal string-based property
API. Suitable for bindings etc. One interesting thing I mentioned was
having abstraction functions for mount and unmount. Btw, HAL really only
tries to target UNIX-like systems and most, if not all, of these got
a /bin/mount. 

> _so_ :)
> 
> this is fun!
> 
> btw i'm getting there with the automount stuff in hald:
> 
> - i've added into fstab-sync (in-autofs-mode) some code that updates
>   "volume.mount_point".
> 
> - after the hal_callout_device() in detect_media() i run a
>   "VolumeMount" notify (which i think should be VolumeAutoMount).
> 
> - i've switched off VolumeMount and VolumeUmount notifies from
>   /etc/mtab parsing.
> 
> more to do...
> 

I'm a little lost here, sorry; is the goal to provide the exact same hal
API (e.g. volume.is_mounted, volume.mount_point, volume.fstype etc.) to
applications as if we weren't using autofs? But with the following
changes:

1. The added benefit that the user can actually remove usb sticks and
cdrom media after they haven't been written to for some time?

2. Real mounting happens at root level on-demand?

3. The applications thinks the volume got mounted once it is inserted.

David

_______________________________________________
hal mailing list
hal at freedesktop.org
http://freedesktop.org/mailman/listinfo/hal