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. Hopefully me comments on avoiding conflict will be useful.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 appreciatedI 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. -- E. Robert Bogusta It seemed like a good idea at the time |
- Re: Automounters - more info wanted (was Re: Re: plextor p... Lourens Veen
- Re: Automounters - more info wanted (was Re: Re: plex... Volker Kuhlmann
- Re: Automounters - more info wanted (was Re: Re: ... Lourens Veen
- Re: Automounters - more info wanted (was Re: ... Volker Kuhlmann
- Re: Automounters - more info wanted (was ... Rob Bogus
- Re: Automounters - more info wanted ... Lourens Veen
- Re: Automounters - more info wan... Volker Kuhlmann
- Re: Automounters - more info wan... Lourens Veen
- Re: Automounters - more info wan... Andy Polyakov
- Re: Automounters - more info wanted ... Rob Bogus
- Re: Automounters - more info wanted (was Re: Re: plextor p... Rob Bogus
- Re: Automounters - more info wanted (was Re: Re: plextor p... Joerg Schilling
- Re: Automounters - more info wanted (was Re: Re: plex... Lourens Veen
- Re: Automounters - more info wanted (was Re: Re: plex... Andy Polyakov
- Re: Automounters - more info wanted (was Re: Re: plextor p... Joerg Schilling
- Re: Automounters - more info wanted (was Re: Re: plextor p... Joerg Schilling
- Re: Automounters - more info wanted (was Re: Re: plextor p... Joerg Schilling