Re: Automounters - more info wanted (was Re: Re: plextor px-708uf: cannot get disk type)
Rob Bogus wrote: Volker Kuhlmann wrote: What I meant was those autothingies should keep their hands off a disk while a burn process is happening. Dunno whether it's possible to detect this, but isn't that the way it should be? The burner software can open exclusive - see man open. After looking at how that's actually done, I don't know if that's going to work for a device as well as it would for a file. Actually, I don't think it will work at all. I also looked a flock() and fcntl(), which have the same problem, and lock() which doesn't seem to even be implemented yet. Add to that the problems which relate to having multiple directories created with mknod which are really the same device, and it doesn't look as if driver level locking is practical after all. Devices don't behave as files! -- E. Robert Bogusta It seemed like a good idea at the time -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Automounters - more info wanted (was Re: Re: plextor px-708uf: cannot get disk type)
Rob Bogus wrote: Volker Kuhlmann wrote: What I meant was those autothingies should keep their hands off a disk while a burn process is happening. Dunno whether it's possible to detect this, but isn't that the way it should be? The burner software can open exclusive - see man open. After looking at how that's actually done, I don't know if that's going to work for a device as well as it would for a file. Actually, I don't think it will work at all. I also looked a flock() and fcntl(), which have the same problem, and lock() which doesn't seem to even be implemented yet. Add to that the problems which relate to having multiple directories created with mknod which are really the same device, and it doesn't look as if driver level locking is practical after all. Devices don't behave as files! -- E. Robert Bogusta It seemed like a good idea at the time
Re: Automounters - more info wanted (was Re: Re: plextor px-708uf: cannot get disk type)
From [EMAIL PROTECTED] Sat Jan 31 16:27:44 2004 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. There _may_ be a GUI _to_ the NON-GUI volume management, but the volume management itself does not belong into the GUI. --010302030009000204040203 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit !DOCTYPE html PUBLIC -//W3C//DTD HTML 4.01 Transitional//EN html head START TO LEARN HOW TO MAIL! confugure your mailer so there is NO HTML Keinen HTML Muell bitte! No HTML junk please! Jörg -- EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin [EMAIL PROTECTED](uni) If you don't have iso-8859-1 [EMAIL PROTECTED](work) chars I am Jorg Schilling URL: http://www.fokus.fraunhofer.de/usr/schilling ftp://ftp.berlios.de/pub/schily -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Automounters - more info wanted (was Re: Re: plextor px-708uf: cannot get disk type)
On Sat 31 January 2004 22:46, Volker Kuhlmann wrote: What I meant was those autothingies should keep their hands off a disk while a burn process is happening. Dunno whether it's possible to detect this, but isn't that the way it should be? The burner software can open exclusive - see man open. Yes, even better if the burning software can get access to the device in such a way that accesses from other processes result in in use - go away. You mean O_EXCL? That doesn't seem to make sense? O_EXCL When used with O_CREAT, if the file already exists it is an error and the open will fail. My man page doesn't mention anything about E_EXCL when used without O_CREAT, but if the behaviour is return success only when the device isn't in use (r or w elsewhere) and to prevent subsequent processes from opening even read-only, then that looks As far as I can tell, it says that it won't create or open the file if it already exists. I'm just going by the manpage, but it doesn't say anything about just opening without O_CREAT (and I reckon the device file would exist), let alone that this would prevent other programs from opering. If it would work without O_CREAT _and_ these automounter opened with O_EXCL, then it might be the solution. But I don't see that written down anywhere... Lourens -- GPG public key: http://home.student.utwente.nl/l.e.veen/lourens.key
Re: Automounters - more info wanted (was Re: Re: plextor px-708uf: cannot get disk type)
Lourens Veen wrote: On Tue 27 January 2004 11:16, Lourens Veen wrote: On Tue 27 January 2004 08:06, Lourens Veen wrote: Then there is autofs (http://freshmeat.net/projects/autofs/?topic_id=142, can't find a real homepage) and KDE uses fam (http://oss.sgi.com/projects/fam/), however I don't think fam actually mounts devices by itself, it just watches files. I use (parts of) KDE myself and fam is almost always running; it's never given me any problems with writing CDs. It turns out that there is a daemon similar to magicdev, which is used with KDE: autorun (http://sourceforge.net/projects/autorun/). From the description: I just found out that both magicdev and autorun originated at Red Hat. It seems somebody decided they needed automounting functionality, even if it meant a security weakness, and they implemented it for both GNOME and KDE, as magicdev and autorun respectively. It seems like these are separate packages, so I think the best thing to do is to recommend uninstalling them wholesale. I'll try and get a patch to README.volmgt together this weekend. I'm not sure what you would patch, some instructions on how to disable the feature in the GNOME menus would be appropriate. It's easy to use a hammer, I removed execute permissions from the executable, but there is a way to control the feature properly. The preferences-CD_properties doesn't seem to be the only place to disable. -- E. Robert Bogusta It seemed like a good idea at the time
Re: Automounters - more info wanted (was Re: Re: plextor px-708uf: cannot get disk type)
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
Re: Automounters - more info wanted (was Re: Re: plextor px-708uf: cannot get disk type)
Volker Kuhlmann wrote: What I meant was those autothingies should keep their hands off a disk while a burn process is happening. Dunno whether it's possible to detect this, but isn't that the way it should be? The burner software can open exclusive - see man open. -- E. Robert Bogusta It seemed like a good idea at the time -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Automounters - more info wanted (was Re: Re: plextor px-708uf: cannot get disk type)
Joerg Schilling wrote: From: Lourens Veen [EMAIL PROTECTED] NO, if you like to check for a media change you need to access the TOC. Thanks, but that's not what I was asking. What I want to know is, if I were writing a volume management system, and I wanted to make sure it didn't interfere with a write in progress, is there any way for it to find out if a disk is being written without disturbing a write in progress? NO Joerg is correct, but it's certainly possible to see if a resource is in use, easily in the kernel and usefully in user space. However, I think the desirable thing is for the burning software to protect its resource rather than depend on other software to be curner aware. -- E. Robert Bogusta It seemed like a good idea at the time
Re: Automounters - more info wanted (was Re: Re: plextor px-708uf: cannot get disk type)
On Sat 31 January 2004 16:30, Rob Bogus wrote: Volker Kuhlmann wrote: What I meant was those autothingies should keep their hands off a disk while a burn process is happening. Dunno whether it's possible to detect this, but isn't that the way it should be? The burner software can open exclusive - see man open. You mean O_EXCL? That doesn't seem to make sense? Lourens -- GPG public key: http://home.student.utwente.nl/l.e.veen/lourens.key -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Automounters - more info wanted (was Re: Re: plextor px-708uf: cannot get disk type)
What I meant was those autothingies should keep their hands off a disk while a burn process is happening. Dunno whether it's possible to detect this, but isn't that the way it should be? The burner software can open exclusive - see man open. Yes, even better if the burning software can get access to the device in such a way that accesses from other processes result in in use - go away. You mean O_EXCL? That doesn't seem to make sense? O_EXCL When used with O_CREAT, if the file already exists it is an error and the open will fail. My man page doesn't mention anything about E_EXCL when used without O_CREAT, but if the behaviour is return success only when the device isn't in use (r or w elsewhere) and to prevent subsequent processes from opening even read-only, then that looks like the solution. Does the fact that growisofs/cdrecord don't seem to obtain exclusive access to the device mean doing exactly that isn't actually possible, or prevented otherwise? Volker -- Volker Kuhlmann is possibly list0570 with the domain in header http://volker.dnsalias.net/ Please do not CC list postings to me. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Automounters - more info wanted (was Re: Re: plextor px-708uf: cannot get disk type)
The burner software can open exclusive - see man open. You mean O_EXCL? That doesn't seem to make sense? You must be referring to the fact that O_EXCL is essentially undefined without O_CREAT. It's absolutely true, but it doesn't mean that it's not passed down to kernel, most notably when you open a device. And as long as it's passed down, the device driver is free to interpret it. The latter means that there is no guaranteed/specified common meaning for O_EXCL flag and it might and does vary from implementation to implementation. E.g. Linux cdrom doesn't pay any attention to O_EXCL. Solaris sd driver respects it, but not the vol driver (the one I called bypass device in my previous post in this thread). A. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Automounters - more info wanted (was Re: Re: plextor px-708uf: cannot get disk type)
On Sat 31 January 2004 22:46, Volker Kuhlmann wrote: What I meant was those autothingies should keep their hands off a disk while a burn process is happening. Dunno whether it's possible to detect this, but isn't that the way it should be? The burner software can open exclusive - see man open. Yes, even better if the burning software can get access to the device in such a way that accesses from other processes result in in use - go away. You mean O_EXCL? That doesn't seem to make sense? O_EXCL When used with O_CREAT, if the file already exists it is an error and the open will fail. My man page doesn't mention anything about E_EXCL when used without O_CREAT, but if the behaviour is return success only when the device isn't in use (r or w elsewhere) and to prevent subsequent processes from opening even read-only, then that looks As far as I can tell, it says that it won't create or open the file if it already exists. I'm just going by the manpage, but it doesn't say anything about just opening without O_CREAT (and I reckon the device file would exist), let alone that this would prevent other programs from opering. If it would work without O_CREAT _and_ these automounter opened with O_EXCL, then it might be the solution. But I don't see that written down anywhere... Lourens -- GPG public key: http://home.student.utwente.nl/l.e.veen/lourens.key -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Automounters - more info wanted (was Re: Re: plextor px-708uf: cannot get disk type)
Joerg Schilling wrote: From: Lourens Veen [EMAIL PROTECTED] NO, if you like to check for a media change you need to access the TOC. Thanks, but that's not what I was asking. What I want to know is, if I were writing a volume management system, and I wanted to make sure it didn't interfere with a write in progress, is there any way for it to find out if a disk is being written without disturbing a write in progress? NO Joerg is correct, but it's certainly possible to see if a resource is in use, easily in the kernel and usefully in user space. However, I think the desirable thing is for the burning software to protect its resource rather than depend on other software to be curner aware. -- E. Robert Bogusta It seemed like a good idea at the time
Re: Automounters - more info wanted (was Re: Re: plextor px-708uf: cannot get disk type)
On Sat 31 January 2004 16:30, Rob Bogus wrote: Volker Kuhlmann wrote: What I meant was those autothingies should keep their hands off a disk while a burn process is happening. Dunno whether it's possible to detect this, but isn't that the way it should be? The burner software can open exclusive - see man open. You mean O_EXCL? That doesn't seem to make sense? Lourens -- GPG public key: http://home.student.utwente.nl/l.e.veen/lourens.key
Re: Automounters - more info wanted (was Re: Re: plextor px-708uf: cannot get disk type)
What I meant was those autothingies should keep their hands off a disk while a burn process is happening. Dunno whether it's possible to detect this, but isn't that the way it should be? The burner software can open exclusive - see man open. Yes, even better if the burning software can get access to the device in such a way that accesses from other processes result in in use - go away. You mean O_EXCL? That doesn't seem to make sense? O_EXCL When used with O_CREAT, if the file already exists it is an error and the open will fail. My man page doesn't mention anything about E_EXCL when used without O_CREAT, but if the behaviour is return success only when the device isn't in use (r or w elsewhere) and to prevent subsequent processes from opening even read-only, then that looks like the solution. Does the fact that growisofs/cdrecord don't seem to obtain exclusive access to the device mean doing exactly that isn't actually possible, or prevented otherwise? Volker -- Volker Kuhlmann is possibly list0570 with the domain in header http://volker.dnsalias.net/ Please do not CC list postings to me.
Re: Automounters - more info wanted (was Re: Re: plextor px-708uf: cannot get disk type)
From [EMAIL PROTECTED] Wed Jan 28 21:01:50 2004 Is there any way at all to check whether a CD is being written without disturbing the writing process? NO, if you like to check for a media change you need to access the TOC. This is why accessing the drive for writing needs to suspend the volume management until the writing has been completed. Jörg -- EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin [EMAIL PROTECTED](uni) If you don't have iso-8859-1 [EMAIL PROTECTED](work) chars I am Jorg Schilling URL: http://www.fokus.fraunhofer.de/usr/schilling ftp://ftp.berlios.de/pub/schily -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Automounters - more info wanted (was Re: Re: plextor px-708uf: cannot get disk type)
On Thu 29 January 2004 12:34, Joerg Schilling wrote: From [EMAIL PROTECTED] Wed Jan 28 21:01:50 2004 Is there any way at all to check whether a CD is being written without disturbing the writing process? NO, if you like to check for a media change you need to access the TOC. Thanks, but that's not what I was asking. What I want to know is, if I were writing a volume management system, and I wanted to make sure it didn't interfere with a write in progress, is there any way for it to find out if a disk is being written without disturbing a write in progress? If this is impossible, then for the volume management not to interfere with cdrecord, cdrecord must tell the volume manager that it is writing. Lourens -- GPG public key: http://home.student.utwente.nl/l.e.veen/lourens.key -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Automounters - more info wanted (was Re: Re: plextor px-708uf: cannot get disk type)
From: Lourens Veen [EMAIL PROTECTED] NO, if you like to check for a media change you need to access the TOC. Thanks, but that's not what I was asking. What I want to know is, if I were writing a volume management system, and I wanted to make sure it didn't interfere with a write in progress, is there any way for it to find out if a disk is being written without disturbing a write in progress? NO If this is impossible, then for the volume management not to interfere with cdrecord, cdrecord must tell the volume manager that it is writing. Well, the volume management on Solaris allows to do this by opening e.g. /vol/dev/rdsk/c1t1d0/unknown_format The correct name is retrieved by asking the volmgt system. Jörg -- EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin [EMAIL PROTECTED](uni) If you don't have iso-8859-1 [EMAIL PROTECTED](work) chars I am Jorg Schilling URL: http://www.fokus.fraunhofer.de/usr/schilling ftp://ftp.berlios.de/pub/schily -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Automounters - more info wanted (was Re: Re: plextor px-708uf: cannot get disk type)
On Tue 27 January 2004 11:16, Lourens Veen wrote: On Tue 27 January 2004 08:06, Lourens Veen wrote: Then there is autofs (http://freshmeat.net/projects/autofs/?topic_id=142, can't find a real homepage) and KDE uses fam (http://oss.sgi.com/projects/fam/), however I don't think fam actually mounts devices by itself, it just watches files. I use (parts of) KDE myself and fam is almost always running; it's never given me any problems with writing CDs. It turns out that there is a daemon similar to magicdev, which is used with KDE: autorun (http://sourceforge.net/projects/autorun/). From the description: I just found out that both magicdev and autorun originated at Red Hat. It seems somebody decided they needed automounting functionality, even if it meant a security weakness, and they implemented it for both GNOME and KDE, as magicdev and autorun respectively. It seems like these are separate packages, so I think the best thing to do is to recommend uninstalling them wholesale. I'll try and get a patch to README.volmgt together this weekend. Lourens -- GPG public key: http://home.student.utwente.nl/l.e.veen/lourens.key -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Automounters - more info wanted (was Re: Re: plextor px-708uf: cannot get disk type)
True, but having an automounter like autofs would be an easy way of implementing this, and it has the advantage that it'll also work from outside of the DE. Hm, true. Any distro actually using autofs though? SuSE isn't, don't know about others. Can one assume that people who use the command line these days ought to know what they're doing? But that means that you lose all functionality if you have a single writer in the machine that is also used for reading. If you want it to work for already-written CDs, and yet not interfere with burning, then unless there is a non-interfering way of determining the disk type and/or whether it is being written, this is impossible. What I meant was those autothingies should keep their hands off a disk while a burn process is happening. Dunno whether it's possible to detect this, but isn't that the way it should be? Sorry, can't help further. Volker -- Volker Kuhlmann is possibly list0570 with the domain in header http://volker.dnsalias.net/ Please do not CC list postings to me. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Automounters - more info wanted (was Re: Re: plextor px-708uf: cannot get disk type)
On Wed 28 January 2004 16:07, Joerg Schilling wrote: From [EMAIL PROTECTED] Tue Jan 27 21:08:37 2004 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. This is a reason why Apple and Sun introduced such a beast on the 1980s So how about this. We run a normal automounter. The volume manager does not actually mount disks, but just reads the volume label. This is enough to interrupt the CD writing process in a way that creates a coaster. Is there any way at all to check whether a CD is being written without disturbing the writing process? Lourens -- GPG public key: http://home.student.utwente.nl/l.e.veen/lourens.key -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Automounters - more info wanted (was Re: Re: plextor px-708uf: cannot get disk type)
From [EMAIL PROTECTED] Tue Jan 27 21:08:37 2004 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. This is a reason why Apple and Sun introduced such a beast on the 1980s So how about this. We run a normal automounter. The volume manager does not actually mount disks, but just reads the volume label. This is enough to interrupt the CD writing process in a way that creates a coaster. 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 that the Sun volume mamager performs a dummy mount for empty medium and remains quiet until you call eject cd. Unfortunately this does not help when you like to write multi session CDs. 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. The big problem with REdHat and SuSE is that they are trying to make their Linux distribution more and more proprietary (differ from others). 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. OK, please do and report your results. Jörg -- EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin [EMAIL PROTECTED](uni) If you don't have iso-8859-1 [EMAIL PROTECTED](work) chars I am Jorg Schilling URL: http://www.fokus.fraunhofer.de/usr/schilling ftp://ftp.berlios.de/pub/schily -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Automounters - more info wanted (was Re: Re: plextor px-708uf: cannot get disk type)
It seems that the Sun volume mamager performs a dummy mount for empty medium and remains quiet until you call eject cd. Upon CD/DVD media load Solaris volume manager arranges kind of bypass device entry under /vol and then invokes rmmount. Rmmount analyzes the media to identify the file system layout and mounts the bypass device entry arranged in previous step under /cdrom/label if it a file system was in fact found. And that is *all*. Solaris volume manager does not care if rmmount succeeded or not and in fact remains totally unaware of the mount point. It does not monitor the device [nor mount point] till the media eject is requested [regardless if the media was empty or not]. Upon eject the bypass device entry is destroyed (ioctl is intercepted and routed to volume manager). For the reference /vol itself is an NFS mount point, and volume manager acts as user-land NFS server for it. /vol is basically just a way to expose bypass device entries to the user-land and no automounting-like activities are going on there. Unfortunately this does not help when you like to write multi session CDs. As volume manager is not aware of the mount point, you can simply 'umount /cdrom/label' and proceed with multi-session recording. Works for DVD multi-sessioning... Well, there is one thing which can ruin recording, 'volrmmount -i cdrom' issued during recording. A. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Automounters - more info wanted (was Re: Re: plextor px-708uf: cannot get disk type)
On Wed 28 January 2004 00:28, Volker Kuhlmann wrote: or whatever. Then when the user actually opens the drive, the automounter kicks in and it is mounted. In this case, you simply don't need an automounter, and SuSE shows that nicely. User wants to open hard disk? - Click harddisk icon. User wants to open CD? - Click CD icon. I'm sure my mother would be able to manage that. Neither KDE nor gnome automounters are even shipped by SuSE. Given the amount of trouble with them, one could call it foresight ;) I use autofs because I chose to manually enable it. True, but having an automounter like autofs would be an easy way of implementing this, and it has the advantage that it'll also work from outside of the DE. To reiterate, we still need to know how to disable KDE autorun and GNOME magicdev for a single drive. I'd say these programs are broken if they cause coasters during burning. This is not for cdrecord/growisofs to fix. Lodge a problem report and urgent fix request with their maintainers, and meanwhile include a stern warning with burning software to obliterate this kind of nuisance software from the system during burning. Well, I'd prefer to be a bit more subtle, and explain how to disable it for selected drives rather than removing it entirely. But to write the doc I need to know how... Ideally, there would be a way to tell automount and magicdev to turn this off from a program. IMHO ideally these programs would be smart enough to keep their hands off things which they otherwise break. But that means that you lose all functionality if you have a single writer in the machine that is also used for reading. If you want it to work for already-written CDs, and yet not interfere with burning, then unless there is a non-interfering way of determining the disk type and/or whether it is being written, this is impossible. Lourens -- GPG public key: http://home.student.utwente.nl/l.e.veen/lourens.key
Re: Automounters - more info wanted (was Re: Re: plextor px-708uf: cannot get disk type)
True, but having an automounter like autofs would be an easy way of implementing this, and it has the advantage that it'll also work from outside of the DE. Hm, true. Any distro actually using autofs though? SuSE isn't, don't know about others. Can one assume that people who use the command line these days ought to know what they're doing? But that means that you lose all functionality if you have a single writer in the machine that is also used for reading. If you want it to work for already-written CDs, and yet not interfere with burning, then unless there is a non-interfering way of determining the disk type and/or whether it is being written, this is impossible. What I meant was those autothingies should keep their hands off a disk while a burn process is happening. Dunno whether it's possible to detect this, but isn't that the way it should be? Sorry, can't help further. Volker -- Volker Kuhlmann is possibly list0570 with the domain in header http://volker.dnsalias.net/ Please do not CC list postings to me.
Re: Automounters - more info wanted (was Re: Re: plextor px-708uf: cannot get disk type)
On Wed 28 January 2004 16:07, Joerg Schilling wrote: From [EMAIL PROTECTED] Tue Jan 27 21:08:37 2004 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. This is a reason why Apple and Sun introduced such a beast on the 1980s So how about this. We run a normal automounter. The volume manager does not actually mount disks, but just reads the volume label. This is enough to interrupt the CD writing process in a way that creates a coaster. Is there any way at all to check whether a CD is being written without disturbing the writing process? Lourens -- GPG public key: http://home.student.utwente.nl/l.e.veen/lourens.key
Re: Automounters - more info wanted (was Re: Re: plextor px-708uf: cannot get disk type)
It seems that the Sun volume mamager performs a dummy mount for empty medium and remains quiet until you call eject cd. Upon CD/DVD media load Solaris volume manager arranges kind of bypass device entry under /vol and then invokes rmmount. Rmmount analyzes the media to identify the file system layout and mounts the bypass device entry arranged in previous step under /cdrom/label if it a file system was in fact found. And that is *all*. Solaris volume manager does not care if rmmount succeeded or not and in fact remains totally unaware of the mount point. It does not monitor the device [nor mount point] till the media eject is requested [regardless if the media was empty or not]. Upon eject the bypass device entry is destroyed (ioctl is intercepted and routed to volume manager). For the reference /vol itself is an NFS mount point, and volume manager acts as user-land NFS server for it. /vol is basically just a way to expose bypass device entries to the user-land and no automounting-like activities are going on there. Unfortunately this does not help when you like to write multi session CDs. As volume manager is not aware of the mount point, you can simply 'umount /cdrom/label' and proceed with multi-session recording. Works for DVD multi-sessioning... Well, there is one thing which can ruin recording, 'volrmmount -i cdrom' issued during recording. A.
Re: Automounters - more info wanted (was Re: Re: plextor px-708uf: cannot get disk type)
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 Ick - insert CD, run a program on it. Sounds like desaster to me. Thanks for the warning. I'm using KDE, it's never given any trouble. To mount an inserted CD or to play it, one has to click on the drive's desktop icon. 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 I've been using autofs for years. It's a filesystem(!) which is permanently mounted under /misc. The filesystem is empty. In /etc/auto.misc you configure lines like cd -fstype=auto,ro :/dev/cdrom When accessing the non-existing /misc/cd, autofs does a mkdir /misc/cd and mounts the CD there. After a configurable period of inactivity, it unmounts the CD and removes /misc/cd. It's an automounter which mounts on access. It can mount any filesystem incl windows shares. There is never any interference with CD burning, unless one is silly enough to access /misc/cd during a burn. It's a system daemon, i.e. started via init.d. Volker -- Volker Kuhlmann is possibly list0570 with the domain in header http://volker.dnsalias.net/ Please do not CC list postings to me. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Automounters - more info wanted (was Re: Re: plextor px-708uf: cannot get disk type)
On Tue 27 January 2004 08:06, Lourens Veen wrote: Then there is autofs (http://freshmeat.net/projects/autofs/?topic_id=142, can't find a real homepage) and KDE uses fam (http://oss.sgi.com/projects/fam/), however I don't think fam actually mounts devices by itself, it just watches files. I use (parts of) KDE myself and fam is almost always running; it's never given me any problems with writing CDs. It turns out that there is a daemon similar to magicdev, which is used with KDE: autorun (http://sourceforge.net/projects/autorun/). From the description: autorun automagically recognizes all available CDROMs in the system, mounts them upon insertion of a media and executes a possible autorun executable on the CD. The user can remove the media; autorun will call unmount after that. I did a quick download and looked through the source, and it seems that the binary will be called autorun. I also did a search through the archives and found a reference to supermount (http://supermount-ng.sourceforge.net/). There is also amd, but that doesn't seem to be very widely used, and certainly not installed by default. If someone installed that by hand, they can probably figure out how to fix it. So we have the following table of possible automounters interfering with cdrecord on Linux: Name Type Process name magicdev daemon magicdev? autorundaemon autorun autofsmodule + daemon automount supermountmodule N/A Detecting automounters magicdev and autorun can probably be detected by ps, supermount (or at least supermount-ng) has a /proc/fs/supermount directory. If you are running autofs, you likely have a file called /etc/auto.global, and there is the automount process. Preventing automounters from interfering Ideally, an automounter would detect writing in progress and stay away from the drive while the CD is being written. I don't think any of the abovementioned automounters has such a feature. As an alternative, automounting could be disabled for the writer. autofs is configured through a map file (see the man page) and supermount is configured through /etc/fstab (see the readme). I don't know about autorun and magicdev. As a last resort, the daemon-based automounters could be disabled completely by killing the process and/or uninstalling. The in-kernel ones would have to be disabled through their configuration files, by unloading the module or by recompiling the kernel. Some other bits of information - GNOME uses magicdev - KDE uses autorun, at least on Red Hat - Mandrake includes supermount, but outside of Mandrake it's probably rather rare More info, especially on configuring magicdev and autorun, is still very welcome! Lourens -- GPG public key: http://home.student.utwente.nl/l.e.veen/lourens.key -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Automounters - more info wanted (was Re: Re: plextor px-708uf: cannot get disk type)
From: Lourens Veen [EMAIL PROTECTED] 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:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin [EMAIL PROTECTED](uni) If you don't have iso-8859-1 [EMAIL PROTECTED](work) chars I am Jorg Schilling URL: http://www.fokus.fraunhofer.de/usr/schilling ftp://ftp.berlios.de/pub/schily -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
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 [EMAIL PROTECTED] 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
Re: Automounters - more info wanted (was Re: Re: plextor px-708uf: cannot get disk type)
or whatever. Then when the user actually opens the drive, the automounter kicks in and it is mounted. In this case, you simply don't need an automounter, and SuSE shows that nicely. User wants to open hard disk? - Click harddisk icon. User wants to open CD? - Click CD icon. I'm sure my mother would be able to manage that. Neither KDE nor gnome automounters are even shipped by SuSE. Given the amount of trouble with them, one could call it foresight ;) I use autofs because I chose to manually enable it. To reiterate, we still need to know how to disable KDE autorun and GNOME magicdev for a single drive. I'd say these programs are broken if they cause coasters during burning. This is not for cdrecord/growisofs to fix. Lodge a problem report and urgent fix request with their maintainers, and meanwhile include a stern warning with burning software to obliterate this kind of nuisance software from the system during burning. Ideally, there would be a way to tell automount and magicdev to turn this off from a program. IMHO ideally these programs would be smart enough to keep their hands off things which they otherwise break. Volker -- Volker Kuhlmann is possibly list0570 with the domain in header http://volker.dnsalias.net/ Please do not CC list postings to me. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Automounters - more info wanted (was Re: Re: plextor px-708uf: cannot get disk type)
On Wed 28 January 2004 00:28, Volker Kuhlmann wrote: or whatever. Then when the user actually opens the drive, the automounter kicks in and it is mounted. In this case, you simply don't need an automounter, and SuSE shows that nicely. User wants to open hard disk? - Click harddisk icon. User wants to open CD? - Click CD icon. I'm sure my mother would be able to manage that. Neither KDE nor gnome automounters are even shipped by SuSE. Given the amount of trouble with them, one could call it foresight ;) I use autofs because I chose to manually enable it. True, but having an automounter like autofs would be an easy way of implementing this, and it has the advantage that it'll also work from outside of the DE. To reiterate, we still need to know how to disable KDE autorun and GNOME magicdev for a single drive. I'd say these programs are broken if they cause coasters during burning. This is not for cdrecord/growisofs to fix. Lodge a problem report and urgent fix request with their maintainers, and meanwhile include a stern warning with burning software to obliterate this kind of nuisance software from the system during burning. Well, I'd prefer to be a bit more subtle, and explain how to disable it for selected drives rather than removing it entirely. But to write the doc I need to know how... Ideally, there would be a way to tell automount and magicdev to turn this off from a program. IMHO ideally these programs would be smart enough to keep their hands off things which they otherwise break. But that means that you lose all functionality if you have a single writer in the machine that is also used for reading. If you want it to work for already-written CDs, and yet not interfere with burning, then unless there is a non-interfering way of determining the disk type and/or whether it is being written, this is impossible. Lourens -- GPG public key: http://home.student.utwente.nl/l.e.veen/lourens.key -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Automounters - more info wanted (was Re: Re: plextor px-708uf: cannot get disk type)
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 Ick - insert CD, run a program on it. Sounds like desaster to me. Thanks for the warning. I'm using KDE, it's never given any trouble. To mount an inserted CD or to play it, one has to click on the drive's desktop icon. 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 I've been using autofs for years. It's a filesystem(!) which is permanently mounted under /misc. The filesystem is empty. In /etc/auto.misc you configure lines like cd -fstype=auto,ro :/dev/cdrom When accessing the non-existing /misc/cd, autofs does a mkdir /misc/cd and mounts the CD there. After a configurable period of inactivity, it unmounts the CD and removes /misc/cd. It's an automounter which mounts on access. It can mount any filesystem incl windows shares. There is never any interference with CD burning, unless one is silly enough to access /misc/cd during a burn. It's a system daemon, i.e. started via init.d. Volker -- Volker Kuhlmann is possibly list0570 with the domain in header http://volker.dnsalias.net/ Please do not CC list postings to me.
Re: Automounters - more info wanted (was Re: Re: plextor px-708uf: cannot get disk type)
On Tue 27 January 2004 08:06, Lourens Veen wrote: Then there is autofs (http://freshmeat.net/projects/autofs/?topic_id=142, can't find a real homepage) and KDE uses fam (http://oss.sgi.com/projects/fam/), however I don't think fam actually mounts devices by itself, it just watches files. I use (parts of) KDE myself and fam is almost always running; it's never given me any problems with writing CDs. It turns out that there is a daemon similar to magicdev, which is used with KDE: autorun (http://sourceforge.net/projects/autorun/). From the description: autorun automagically recognizes all available CDROMs in the system, mounts them upon insertion of a media and executes a possible autorun executable on the CD. The user can remove the media; autorun will call unmount after that. I did a quick download and looked through the source, and it seems that the binary will be called autorun. I also did a search through the archives and found a reference to supermount (http://supermount-ng.sourceforge.net/). There is also amd, but that doesn't seem to be very widely used, and certainly not installed by default. If someone installed that by hand, they can probably figure out how to fix it. So we have the following table of possible automounters interfering with cdrecord on Linux: Name Type Process name magicdev daemon magicdev? autorundaemon autorun autofsmodule + daemon automount supermountmodule N/A Detecting automounters magicdev and autorun can probably be detected by ps, supermount (or at least supermount-ng) has a /proc/fs/supermount directory. If you are running autofs, you likely have a file called /etc/auto.global, and there is the automount process. Preventing automounters from interfering Ideally, an automounter would detect writing in progress and stay away from the drive while the CD is being written. I don't think any of the abovementioned automounters has such a feature. As an alternative, automounting could be disabled for the writer. autofs is configured through a map file (see the man page) and supermount is configured through /etc/fstab (see the readme). I don't know about autorun and magicdev. As a last resort, the daemon-based automounters could be disabled completely by killing the process and/or uninstalling. The in-kernel ones would have to be disabled through their configuration files, by unloading the module or by recompiling the kernel. Some other bits of information - GNOME uses magicdev - KDE uses autorun, at least on Red Hat - Mandrake includes supermount, but outside of Mandrake it's probably rather rare More info, especially on configuring magicdev and autorun, is still very welcome! Lourens -- GPG public key: http://home.student.utwente.nl/l.e.veen/lourens.key
Re: Automounters - more info wanted (was Re: Re: plextor px-708uf: cannot get disk type)
From: Lourens Veen [EMAIL PROTECTED] 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:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin [EMAIL PROTECTED](uni) If you don't have iso-8859-1 [EMAIL PROTECTED](work) chars I am Jorg Schilling URL: http://www.fokus.fraunhofer.de/usr/schilling ftp://ftp.berlios.de/pub/schily
Re: Automounters - more info wanted (was Re: Re: plextor px-708uf: cannot get disk type)
or whatever. Then when the user actually opens the drive, the automounter kicks in and it is mounted. In this case, you simply don't need an automounter, and SuSE shows that nicely. User wants to open hard disk? - Click harddisk icon. User wants to open CD? - Click CD icon. I'm sure my mother would be able to manage that. Neither KDE nor gnome automounters are even shipped by SuSE. Given the amount of trouble with them, one could call it foresight ;) I use autofs because I chose to manually enable it. To reiterate, we still need to know how to disable KDE autorun and GNOME magicdev for a single drive. I'd say these programs are broken if they cause coasters during burning. This is not for cdrecord/growisofs to fix. Lodge a problem report and urgent fix request with their maintainers, and meanwhile include a stern warning with burning software to obliterate this kind of nuisance software from the system during burning. Ideally, there would be a way to tell automount and magicdev to turn this off from a program. IMHO ideally these programs would be smart enough to keep their hands off things which they otherwise break. Volker -- Volker Kuhlmann is possibly list0570 with the domain in header http://volker.dnsalias.net/ Please do not CC list postings to me.
