You are using a too old version of mkisofs. It needs the mkisofs found in cdrtools-1.10a16 or later (mkisofs is distributed in cdrtools nowadays, check with mkisofs --version, mkisofs should be at least version 1.14a16). Check the warning gcombust prints at startup (from an xterm) and the changelog for more information.
This discussion might be Linux centric. If it doesn't apply for your favorite OS, send an addition, meaningless OS-war complaints will be ignored.
gcombust shouldn't be ran as root (running it as root won't make you self-combust, but it's nevertheless a good idea to minimize root usage).
There are two reasons for running cdrecord with root priviligies; 1) real time priority and 2) locking the buffers (so they can't get swapped out). cdrecord can be run without root privligies, but it increases the chance of a buffer underrun. cdrecord also needs read/write access to the cdr-device (for making multisession cd:s mkisofs also needs read access to the device). Please understand that making cdrecord suid root is a security risk.
First, the non-root sollution (this should be quite safe, but I'm no scsi guru, you are granting write access to a scsi device..):
1) create a group for user who should be allowed to burn ("addgroup cdburn")
2) add user to this group ("adduser joedoe cdburn")
3) change the group owner of the device to cdburn, and give it group read/wright rights
("chgrp cdburn /dev/scd0; chmod g+rw")
The setuid-root sollution (give only the group executable rights, make it suid root), please note that this is a security risk - you have been warned):
1) create a group and add users as above
2) remove world executable from cdrecord ("chmod o-x /usr/bin/cdrecord")
3) make cdrecord setuid root ("chown root /usr/bin/cdrecord; chmod u+s /usr/bin/cdrecord")
4) make the group of cdrecord the newly created group ("chgrp cdburn /usr/bin/cdrecord")
Now, only users in the cdburn group can execute cdrecord, and it will be executed with
root priviligies.
For mkisofs, it should be enough to give the users read right to the cdr device (needed for multisession).
Well, you can. The limitation is in the GTK+ file requester widget, there is no way to tell it to automatically show .-files. However, entering a . as the filename and pressing the tab key will show the hidden files.
This won't be added. Not by me anyway. I tried doing it about 6 months ago. I
got it running, but it was unstable as h*ll. Making this work would require
rewriting a lot of code (gcombust was my first larger programming project - the
design of some parts stinks - it was never meant to grow so many features, originally
it was just supposed to generate filename listings for mkisofs!).
Cleaning up the code would be more trouble than
rewriting, so I decided to join forces with cdrdao/xcdrdao ((other page). Unfortunately I haven't
had time to do anything for this project yet. This feature is planned for
xcdrdao.
I have been told gnome-toaster supports
on-the-fly-recording of mp3 files using cdrdao, although I haven't tried it myself yet.
gcombust has some rundamentary support for renaming files/directories since version 0.1.34. But for more advanced features, see above.
You want to help coding? Just start coding on something (hear the wise words of ESR: "To solve an interesting problem, start by finding a problem that is interesting to you."), then send me a patch. I regularely get mail from people saying they will start coding, but I never hear back from them... I thought the gcombust source had some X-Files-qualities (either that, or the code is horrible, scaring people away :), but this free-source phenomenon is actually documented somewhere.
If you can't code, you can still help. Please, please write some user documentation for gcombust! Currently you have to be familiar with cdburning in general and specifically cdrtools to really understand the features of gcombust. Some primer/documentation would really do wonders I think!
Yes, this would be a useful feature for slower machines. The only obstacle is to deal with characters in the file names that need escaping. To really work well, I think a (small) external program would still be needed. But when I figure out a good sollution (and, more importantly, time to sit down and implement it!) I'll add it.
Sorry. I forget. I run out of time. Real Life comes in the way. (Oh, well, that last point was a lie, I don't really have a Real Life :). Please email me again!
There's really not much use in sending me dumps of cdrecord errors. I don't
know much about cdrecord errors. You should report them to the cdrecord author,
Joerg Schilling, or the cdwrite mailinglist (the mail addresses can be found in
the cdrecord manpage). See
http://www.fokus.gmd.de/research/cc/glone/employees/joerg.schilling/private/problems.html
for more information.
Two hints: Don't use gcombust when generating error messages from cdrecord. gcombust
might accidentaly cut out important information, use cdrecord from the commandline to
make sure gcombust doesn't screw up anything, mmkay? Secondly, make sure you have tried
with the latest version of cdrecord, it might very well fix the problem.
(c) Jonas Munsin
File last modified on Saturday, 02-Feb-2002 05:29:47 EST