no.top.post@gmail.com wrote:
> After finally spending a few minutes testing the 2009 ver. KDE
> I'm trying to make a DVD backup of my most important data.
>
> I seem to remember that when I looked at a `man` ten years ago
> it showed the man-ID and that I was on line 843 of 1352 total
> lines. So that when I skipped between man A & man B, I could
> see which one I was looking at, and if it was the one with the
> stuff at approximately 40% in the man.
>
> That seems a real useful facility compared to the dancing-cartoonS
> of newer-kde.
> Eg. when you're reading `man cdrecord` and it's got paragraphs
> about 'mkisofs`, you don't need to wonder if you're reading the
> 'man mkisofs', which you opened somewhere else.
>
> Why does `cdrecord --help | wc -l`
> show "0", so now I've got no evidence of how many switches
> this absurd utility lists?
> And, related: `cdrecord --help | less` scrolls to the end, so
> that you can't see the most-important: up-front <syntax>.
>
> How does the dancing-cartoon version manage to work like
> a toaster without a zillion switches?
>
> I finally found where 1GB of `df` went to, by `mkisofs`
> but is there any way to ask to `find <files BIGGER THAN nKB>` ?
> ---------
> Previously [according to my log-notes] the minimal:
> `mkisofs -R <dir-tree> | cdrecord <device args>`
> saved files with DOS:8.3 names -- which is crap!!
>
> Now I've spent hours generating a log of failures,
> where the latest one is for:-
> ->
> mkisofs -R /mnt/p11 | cdrecord -v fs=6m speed=2 dev=0,0 -
> which reports:-
>> Waiting for reader process to fill input buffer ... cdrecord:
>> Unspecified command not implemented for this drive.
>> cdrecord: Cannot get next writable address.
>> input buffer ready.
>> Writing time: 0.067s
>> Fixating...
>> Fixating time: 0.000s
>> cdrecord: fifo had 96 puts and 0 gets.
>> cdrecord: fifo was 0 times empty and 0 times full, min fill was 100%.
>> mkisofs: Broken pipe. cannot fwrite 32768*1
>
> It seems that the 'fifo is not getting written to'?
> I can't mount blank-DVDs and assumed that 'cdrecord` works
> like `dd`.
> Another 'configuration' reported that <the buffer received a
> premature EOF>
>
> Does anybody know how to save a dir-tree to DVD with these
> 2 old utilities, instead of with a dancing cartoons utility?
>
> == TIA.
>
Why you asked this in alt.comp.hardware, I'll never know.
This is a question about commands with a zillion options.
Such a design implies the person writing the software (mkisofs, cdrecord)
wants *you* to waste hours of your time, figuring it out. It's
meant to be annoying. It's highly unlikely a person with
a polished, command line invocation, is reading this thread.
Use the cartoon version, if you don't have hours to spend, and
a pile of CDs to waste. Brasero sucks. Don't use it. I use K3B,
and like it enough, I remastered a Ubuntu LiveCD, tossing OpenOffice,
just so I could have a copy of K3B in a Gnome environment. The feedback
you get from K3B, while attempting to burn an ISO, is very useful if
you've forgotten a step (like, forgot to erase your rewritable media).
(K3B is a KDE utility, which means sucking in half of KDE just so you
can have it.)
*******
http://lmgtfy.com/?q=mkisofs+cdrecord
(There are lots of tutorials around. This one doesn't answer the question
so I move on.)
http://www.ibm.com/developerworks/li...urn/index.html
(OK, now we're getting some where.)
http://cdrecord.berlios.de/private/m...ord/index.html http://cdrecord.berlios.de/private/m...drecord.1.html
"If the overall speed of the system is sufficient and the
structure of the filesystem is not too complex, cdrecord
will run without creating an image of the ISO-9660 filesystem.
Simply run the pipeline:
mkisofs -R /master/tree | cdrecord -v -dao fs=6m speed=2 dev=2,0 -
So that's an example of a recipe. The "dao" or disk-at-once might make
a difference. Given the large number of arguments these programs take,
I expect a good number of wasted discs until the recipe is right.
ISO9660 stores files in 8.3 mode. But there are options.
http://en.wikipedia.org/wiki/Iso9660
"The standard has three different levels for interchange
Level 1: File names are limited to 8.3, uppercase, 8 directory levels
Level 2: Up to 180 characters. Single byte holds stringlength.
Level 3: Packet writing"
Back to the mkisofs manual page.
http://cdrecord.berlios.de/private/m...mkisofs.8.html
-iso-level level
So there's a level option, which will do a better job on file names.
*******
Note that some software idiots, have spoiled the "pipe" concept in
Linux, by insisting that some commands use up all of system RAM
as a container for the intermediate results. The end result for me,
is now I can no longer trust the "pipe" semantic when I sit down
to use the command line. Good work, boys... (GNU, I'm talking to you...)
What you'll notice is, if you work with large objects (in this case,
that 4GB plus ISO9660 destined for the DVD), *some* Linux tools will
end up trying to use all system RAM to hold the intermediate pipe
contents, instead of using FIFO and blocking until the downstream
command catches up. This results in a "not enough RAM" error, rather
than your piped command sequence completing. Optimization, my ***.
It means some things I used to be able to do in Linux, I can no longer
do.
Paul
What happened to zillion switches in dancing-cartoon version? 
Linear Mode
