[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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 

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.

GPG public key: http://home.student.utwente.nl/l.e.veen/lourens.key

Reply to: