Re: dvd+rw-tools: growisofs exit code
Andy Polyakov wrote: But the catch is that undestanding "why" it happens is most likely the key to solution... Why or why recording just hung half-way and most mysteriously failed with "INVALID ADDRESS FOR WRITE" after a long while... Is there a chance that the drive was opened by another program during failed recording? No, I am quite sure that did not happen. The only user programs running during the backup were an editor and latex. I can't think of any daemons that would access /dev/dvd. I don't think that updatedb ran and even then I don't think that it would open /dev/dvd. *But*... I occasionally mount a dvd to check it contents, and then forget to umount it before rewriting it. I cannot be certain that I didn't do that on this occasion. growisofs does unmount media prior recording. If it fails to, it won't start the recording. So you can keep forgetting to unmount it:-), but you shouldn't "stand" in it (I mean if you cd /mnt/dvd, then attempt to unmount /mnt/dvd fails with "resource busy," and recording won't start). That is a great feature. Have never had a problem with that, but I can see that many new systems I install do seem to have a daemon which mounts media and resists all efforts to permanently kill and deconfigure it. It seems someone can't understand that you may not want to have that happen. -- bill davidsen [EMAIL PROTECTED] CTO TMR Associates, Inc Doing interesting things with small computers since 1979
Re: [Cdrecord-developers] Cdrtools-2.01a25: Patch to make cdrtools 2.01a25 Linux compatible
Ambrose Li wrote: On Tue, Jan 27, 2004 at 10:06:46AM -0500, Greg Wooledge wrote: True -- *but*, it must be pointed out that this is historic! In a modern GNU/Linux distribution, /usr/include/linux should *not* be a symlink to anything at all. It should be a plain directory containing the kernel header files with which the GNU libc was built. If this is true, I must respectfully point out that the real problem is libc6. I upgraded my system to libc6 by hand, and I *never* saw any advice (or "instruction" should be a better word) to make /usr/include/linux a real directory, nor any advice to keep the libc6-compile-time kernel header files anywhere, nor any advice where to put the current kernel header files. Actually that info is in the Linux file standard, which has been available for some years. There are some distributions which don't follow that, all I can say is "there is a standard." If such a drastic change in convention had taken place and I have never read about it when I did my upgrade (which was not very long ago -- I put off upgrading to libc6 until very recently, and I did google for advice for fear of breaking my system), then I have to agree with Joerg that Linux is being very inconsistent, but I will say that the greatest problem is not in the kernel, but in libc6. Without getting into a flame war, he is saying that and then depending on installs to behave in some predictable manner which seems to be blaming Linux (which does have a standard) rather than doing defensive programming. This also implies that cross compilation seems to need source edits, since having /usr/src/linux is optional and would point to the running kernel on the source system if present. It would make life easier for both Joerg and users to state that if the /usr/include/linux headers are not correct for the kernel on which the application will run, then the user must provide the information. As an example: CDRTOOLS_KERNEL_INC=/root/my_2.6_includes make Joerg is willing to put the responsibility for reading the multitude of README files on the user; many times he will point out that someone didn't follow README.multi or similar, and I think he is right. But he doesn't put the responsibility on the user to provide include pointers, and I think that's wrong. cdrtools should use /usr/include/linux unless told otherwise. Trying to guess which headers to use frustrates both the developer and the users, as the endless threads show. Another approach would be to require the user to create a symlink to the includes in the cdrtools directory. And just don't compile until that's done. It not only gives the user a way to get it right, it forces the user to think, which is probably a good thing. Odd distributions are a fact of life, and old distributions which have been updated are, too. I think we have proven that the build system can't correct for all the things people do, so why not make the user supply the information? -- bill davidsen [EMAIL PROTECTED] CTO TMR Associates, Inc Doing interesting things with small computers since 1979
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: [Cdrecord-developers] Cdrtools-2.01a25: Patch to make cdrtools 2.01a25 Linux compatible
Thanos Kyritsis wrote: On Tuesday 27 January 2004 20:39, Robert S. Dubinski wrote: The Filesystem Hierarchy Standard document version 2.3 of the Linux Standard Base project (http://www.linuxbase.org/) lists the following: As a matter of fact, there is also this document: http://www.tldp.org/LDP/Linux-Filesystem-Hierarchy/html/usr.html Now, which one is the right one ?? If FHS is the "right" one, it's obvious it's not complete, but on the contrary it's too general and fails to set a suitable standard for modern Linux distros. Well, I think what Joerg wants to say is clear: Some standard needs to finally direct everyone as to where the running kernel sources are. There are many applications that need the running kernel sources and not /usr/include/linux. That's not at all what you need! You need to compile with the headers for the target kernel, where the application will run, not for the host machine. Now in most cases thay are the same, but you will continue to have problems unless you inderstand this point. -- bill davidsen [EMAIL PROTECTED] CTO TMR Associates, Incs not at all what you need, you need the Doing interesting things with small computers since 1979
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: [Cdrecord-developers] Cdrtools-2.01a25: Patch to make cdrtools 2.01a25 Linux compatible
Actually that info is in the Linux file standard, which has been available for some years. There are some distributions which don't follow that, all I can say is there is a standard. Absolutely. Adhering to the standard should be primary concern, the rest is secondary. cdrtools should use /usr/include/linux unless told otherwise. Yes Odd distributions are a fact of life I maintain that it's the user's responsibility to supply correct headers for the kernel the binary *is being compiled for*. As said before, who said I'm compiling for the running kernel? Users who don't have the clue for this should either use a distro which works, or a pre-compiled binary. Apps should be able to be told where those headers are. Apps saying the headers must be in /usr/src/include aren't all that smart, but it's usable. I return, this also means that software maintainers can't expect everyone to be able to compile the latest alpha^5 version. Saying come back once you've compiled and tried this alpha^5 is unrealistic. 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.
