HAL ejects

[Paul Ionescu]

Hi,

> Most drives don't report "eject button pressed" asynchronously - some HP
> drives do, some others as well, but not a lot. We *could* make hal catch
> this signal (if the drive supports it) and propagate it all the way of
> the stack; it would look like this
> 
>  1. Eject is pressed; door doesn't open 2. (up to 0.999.. seconds later)
>  hald is notified that someone
>     pressed eject; hald broadcasts a signal
>  3. gnome-vfs (or whatever) catches the signal and sends out the
>     preunmount signals
>  4. apps close their open files and ACK's the preunmount 5. gnome-vfs
>  unmounts the drive; if there are still apps with
>     open fd's the unmount fails. gnome-vfs puts up nice dialog.
>  6. door is unlocked; disc is ejected
> 
> But since only few drives support this I'm not happy about providing two
> different user experiences.
> 
>> It is already in FC3
>> I am using it right now.
>> I think it is not in HAL, but in GVM. However, to be able to use it,
>> you have to disable "lock on mount" option of cdrom by "echo 0 >
>> /proc/sys/dev/cdrom/lock" or putting "dev.cdrom.lock = 0" in
>> /etc/sysctl.conf and reloading with sysctl -p.
>> 
>> 
> No, that's bad advice. What happens in that setup is the following
> 
>  1. Eject is pressed; door opens
>  2. hald polls for media; oops no media 3. hald lazy unmounts /dev/cdrom
>  - the media is gone so we have to
>     deal with it somehow; it's better than doing nothing
>  4. all your programs with open fd's on /media/cdrom is screwed

Yes, but M$ Windows users are expecting this behavior. Windows does the
same thing, and there are a lot of people who are used to this. Besides,
there are a lot of programs that will not be ever able to be notified
about an event like this. And usually, in my 5 months experience with it,
the "screwed" programs will just say something about unable to read some
file or directory.

> It's get even more fun if you're writing to the CD.

The writing program can take care of this by locking the CD door when
writing, and restoring after that. If it is packet writing, then it should
be locked on mounting it rw.

> The real solution  is to use something along the lines of volumagic
> which is like supermount but only in userspace.

There is no such thing yet.