Re: Automounters - more info wanted (was Re: Re: plextor px-708uf: cannot get disk type)
>From: Lourens Veen <lourens@rainbowdesert.net>
>"Package: magicdev (1.1.5-1)
>A GNOME daemon for automatically mounting/playing CDs
>Magicdev is a daemon that runs within the GNOME environment and
>detects when a CD is removed or inserted. Magicdev handles running
>autorun programs on the CD, updating the File Manager, and playing
>audio CDs."
>So my above statement was inaccurate, it's not a generic
>automounter.
Well, if you do it right, then then the automounter is the wrong
place for this functionality:
- The task os an automounter is to watch where you try to step in.
If you step into some magic land, it opens a door for you.
If you go out of the magic land, the automounter will make
it disappear.
- The task of a volume management system in on contrary is to
watch the media. If someone inderts a medium, it mounts
this medium if possible.
This is independent to where you step in. It does _not_
unmount the medium if you are obviously not interested in it.
>> Volume management inside KDE or GNOME is completely wrong - it
>> does not belong into a GUI.
>Well, I haven't looked at it in-depth, but it seems to me that
>magicdev is an independent daemon that knows about GNOME and what
>to do when it detects a CD in a drive. It's distributed with GNOME,
>and provides services to it, but that's it. And calling KDE or
>GNOME a GUI is a bit of an understatement too; they're a lot more
>powerful and complex than say, CDE.
KDE seems to have a somilar program. As I don't use Linux (note that
Solaris has a more decent volume management built into the base
operating system since 1992) and Sun obviously did remove the
unwanted features from the Solaris version, I have no idea how
KDE/GNOME on Linux really work.
>I agree that it would be better to have this in a separate subsystem
>though, which could be accessible through HAL
>(http://www.ometer.com/hardware.html).
It makes no sense to have a zillion different volume management systems
on one OS. If you do, it is close to impossible for software authors
to find out how they work and how they might be influenced by
programs like cdrecord.
On Solaris, the problem for many years was that Sun did not write
a man page for vold. Now that a man page is present, it took me
3 years to find the time to add volmgt suppport. But Note: libscg
_does_ have support for the Solaris volmgt system - there is only one!
>> As more and more people get such problems, it would be nice to
>> have an easy to understand desription for recognising the
>> procress from a ps output and what to do to get rid of at least
>> the problems with the burner.
>>From what I've found on the web, to turn off magicdev people just
>uninstall it. Magicdev can be recognised from the above error
>message "This disc doesn't have any tracks I recognize!".
You name the main problem: If there are many different volmgt systems
for Linux, programs like cdrecord cannot support them. The result is that
users just remove all of them if they like to be able to continue using
the whole system :-(
>If there's anyone here actually using magicdev or autofs, more
>information on how to see if it's running and how to configure it
>to stay away from CD writers would be very much appreciated
I would be happy, to see people working on contributions...
Note that if the support is put into e.g. cdrecord.c, it cannot make it
into the official version because this would break portability.
Volmgt support belongs into the OS specific part of libscg.
Jörg
--
EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
js@cs.tu-berlin.de (uni) If you don't have iso-8859-1
schilling@fokus.fraunhofer.de (work) chars I am J"org Schilling
URL: http://www.fokus.fraunhofer.de/usr/schilling ftp://ftp.berlios.de/pub/schily
Reply to: