Re: Automounters - more info wanted (was Re: Re: plextor px-708uf: cannot get disk type)

[Rob Bogus <rob23@tmr.com>]

Joerg Schilling wrote:

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.
  

That's clear explanation of the technical issues.

Volume management inside KDE or GNOME is completely wrong - it
does not belong into a GUI.
      

The GUI is a user interface and should do for the user what the user wishes done. Having the volume management (and that term means something else in most contexts) in the GUI allows the user to control how the system will behave when a specific users is on the console. Anything system-wide would not be doing what the individual users find useful.

NOTE: I'm not saying that's wrong, just that there are good reasons for having this particular feature in the GUI and as a per-user option. I do believe it should be disables for any user not at the console.

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.
  

I note that growisofs unmounts the device if something is using it. I'm not saying you should do that, just that there are ways to cope without knowing anything about the application. I would personally prefer that the application detect that the device is in use and refuce to share. And open exclusive to prevent other access while burning takes place.

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 :-(
  

See above, it's not needed to "support" them, just to stay out of conflict with them. And the term "volume management" as Sun uses it means something other than what AIX (part of JFS admin) and Linux (LVM and DM) usually use. Just so you know if someone gets confused, the term is overloaded.

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.

Hopefully me comments on avoiding conflict will be useful.

-- 
E. Robert Bogusta
  It seemed like a good idea at the time