Sophie

Sophie

distrib > Fedora > 15 > i386 > by-pkgid > 4afa950d6d1727ce4774af84fbf2e889 > files > 7

gcombust-0.1.55-17.i686.rpm

<!DOCTYPE HTML PUBLIC "-//Netscape Comm. Corp.//DTD HTML//EN">

<HTML>
<HEAD>
<TITLE>gcombust faq</TITLE>
</HEAD>
<BODY BGCOLOR="#32323c" TEXT="#80aa90" VLINK="#7777bb" LINK="#aaaaff">

I noticed I kept answering the same questions over and over again, so here it
is:

<CENTER><H1>the gcombust faq</H1></CENTER>

<OL>

<LI><I>When I select a data file to burn, the size is 0. The "update size
estimate" and "compute estimate" buttons do not work, the file size remains
at 0 and gcombust shows 150 sectors used. I use gcombust version 0.1.43 or later.</I><BR>

<P>

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.

<P>

<LI>How do I allow running gcombust as non-root?<BR>

<P>
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.
<P>
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).
<P>
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.
<P>
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..):
<P>
1) create a group for user who should be allowed to burn ("addgroup cdburn")<BR>
2) add user to this group ("adduser joedoe cdburn")<BR>
3) change the group owner of the device to cdburn, and give it group read/wright rights
("chgrp cdburn /dev/scd0; chmod g+rw")<BR>
<P>
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):
<P>
1) create a group and add users as above<BR>
2) remove world executable from cdrecord ("chmod o-x /usr/bin/cdrecord")<BR>
3) make cdrecord setuid root ("chown root /usr/bin/cdrecord; chmod u+s /usr/bin/cdrecord")<BR>
4) make the group of cdrecord the newly created group ("chgrp cdburn /usr/bin/cdrecord")<BR>
Now, only users in the cdburn group can execute cdrecord, and it will be executed with
root priviligies.
<P>
For mkisofs, it should be enough to give the users read right to the cdr device
(needed for multisession).
<P>

<LI>I can't burn hidden files (files starting with a .) using gcombust!<BR>
<P>
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.

<P>

<LI>Please add on-the-fly mp3-to-audio-cd burning...<BR>
<P>
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!).<BR>
Cleaning up the code would be more trouble than
rewriting, so I decided to join forces with <A
HREF="http://sourceforge.net/project/?group_id=2171">cdrdao/xcdrdao</A> (<A
HREF="http://cdrdao.sourceforge.net/">(other page)</A>. Unfortunately I haven't
had time to do anything for this project yet. This feature is planned for
xcdrdao.<BR>
I have been told <A HREF="http://gnometoaster.rulez.org">gnome-toaster</A> supports
on-the-fly-recording of mp3 files using cdrdao, although I haven't tried it myself yet.
<P>
<LI>Please add file mastering/grafting...<BR>
<P>
gcombust has some rundamentary support for renaming files/directories since version 0.1.34.
But for more advanced features, see above.
<P>

<LI>I'd like to help...<BR>
<P>
You want to help coding? Just start coding on something (hear the wise words of <A HREF="http://www.tuxedo.org/~esr/">ESR</A>:
<A HREF="http://www.tuxedo.org/~esr/writings/cathedral-bazaar/cathedral-bazaar-10.html">"To solve an interesting problem, start by finding a problem that is interesting to you."</A>), then
send me a patch.
I <I>regularely</I> 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.
<P>
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!

<P>
<LI>Please add the possability of generating shell scripts for burning cds from the console<BR>
<P>
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.

<P>
<LI>I mailed you this suggestion a few months ago, you said you'd implement it, but nothing has appeared yet...<BR>
<P>
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!

<P>
<LI>About cdrecord problems...<BR>
<P>
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
<a href="http://www.fokus.gmd.de/research/cc/glone/employees/joerg.schilling/private/problems.html">http://www.fokus.gmd.de/research/cc/glone/employees/joerg.schilling/private/problems.html</a>
for more information.<br>

Two hints: <b>Don't use gcombust when generating error messages from cdrecord</b>. 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.

</OL>
<HR>
<A HREF="http://www.vim.org"><IMG BORDER=0 ALIGN=RIGHT SRC="../vim.nagle.anim.just.vim.it.gif"></A>
<ADDRESS><A HREF="MAILTO:jmunsin@iki.N0_SPAM.fi">(c) Jonas Munsin</A></ADDRESS>
<P>
<SMALL><SUP>
<!--#set var="var" value="File last modified on $LAST_MODIFIED" --><!--#echo var="var" -->
</SMALL></SUP>
</P>

</BODY>
</HTML>