Re: Automounters - more info wanted (was Re: Re: plextor px-708uf: cannot get disk type)
On Tue 27 January 2004 12:06, Joerg Schilling wrote:
> 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.
Aha, thanks for explaining that. This does pose a bit of a problem
though if you have both: say I insert a CD, then the volume manager
sees it and mounts it. Then I go to my magic automounter directory
and it tries to mount it too. Problem. Doing away with the
automounter means users have to mount disks by hand (which my mum
would probably find too complicated), while doing away with the
volume management means that users get no feedback after they
inserted a CD in the drive, which is less bad but still undesirable
from a user interface perspective.
So how about this. We run a normal automounter. The volume manager
does not actually mount disks, but just reads the volume label.
This volume label is then sent to the Desktop Environment with a
disk change event, so that the DE can do it's "You just inserted X,
do you want me to do Y" thing or blink the icon and change its name
or whatever. Then when the user actually opens the drive, the
automounter kicks in and it is mounted. This way, the user could
insert a CD, the cut-down volume manager would detect it as empty
and leave it be. The DE, now knowing the CD is empty, can launch
the CD writing application either immediately or when the user
clicks the drive's icon. If the cut-down volume manager and the
automounter can communicate (or are the same system), the
automounter could even refuse to mount the CD when it knows it's an
empty one, thus preventing unwanted accesses that interfere with
writing.
It seems a clean solution to me, and implementable as well. Perhaps
having autofs generate events via DBUS and modifying magicdev and
automount to listen to that instead of to the drive directly, or
removing them entirely, would be enough already. That doesn't mean
it's not a big amount of work though :-).
> >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.
Well, given the amount and size of the differences between different
"Linux" distributions, perhaps it's time to start thinking of them
as different operating systems rather than variations of the same
one. You could do as many other vendors of proprietary software do
and only support one or a few distributions explicitly. They may
still be broken, but at least it makes the job of tracking the
problems a lot more manageable. After all, Linux is just a kernel.
> >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...
Me too, and I volunteer to wrap it all up into a patch to
README.volmgt and a blurb for the dvd+rw-tools website.
To reiterate, we still need to know how to disable KDE autorun and
GNOME magicdev for a single drive.
> 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.
I understand that, but I don't think it's up to cdrecord to fix
this. Automount and magicdev assume that it's always ok to access
the CD drive, which is wrong, because it might interfere with CD
burning. If the user turns them off for the writer, the problem
will be solved, at least for current Linux systems.
Ideally, there would be a way to tell automount and magicdev to turn
this off from a program. If they actually do have such a feature,
it may be possible to have cdrecord disable them automatically
before burning. I don't know enough about either magicdev,
automount or cdrecord to be able to comment on the feasibility of
this. I'll try and find out, but I've got a paper to finish first.
Lourens
--
GPG public key: http://home.student.utwente.nl/l.e.veen/lourens.key
Reply to: