What happened to zillion switches in dancing-cartoon version?

[no.top.post]

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.

 

[Loki Harfagr]

Sat, 07 Apr 2012 10:41:36 +0000, no.top.post did cat :

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

the reason is simple, will you have a guess?
$ cdrecord --help 2>&1 | wc -l
84

this absurd utility lists?

why absurd? if you don't need to use it give it a break,
don't try and think hard about stuff you misread the very first
line...

And, related: `cdrecord --help | less` scrolls to the end, so
that you can't see the most-important: up-front <syntax>.

same punition for stubborn bad-readers ;-)
$ cdrecord --help 2>&1 | less

How does the dancing-cartoon version manage to work like
a toaster without a zillion switches?

probably using the switches behind the smokescreen.

I finally found where 1GB of `df` went to, by `mkisofs`
but is there any way to ask to `find <files BIGGER THAN nKB>` ?

yes, there are several ways to do so, I'd favor 'find'

so many reasons you'd have this in your log-notes, main
might be your "cdrecord" was not the real one (was it
a Debian those years some third dev asst west coast went amok
about rewriting his own bugs nest to demonstrate he wasn't
able to read docs and code?
another favorite reason might be you took wrong notes or
misread the results in a flabbered test attempt?

after all you are the on who's yourself and you should
now try and get used to it so why always coming back in
groups before you tried and give your self a chance?

Now I've spent hours generating a log of failures,

see, you just spent hours to generate failures then log them
that hardly seems the right way to go if you're interested in
going somewhere in the end...

Does anybody know how to save a dir-tree to DVD with these
2 old utilities, instead of with a dancing cartoons utility?

could be, try something along this example:
---------------------
$ cd /...thepathwhereyourgoodiestreeis/
$ mkisofs -o /tmp/yourdvd.iso \
-R -J -A "most important data bkup" \
-hide-rr-moved \
-v -d -N \
-m 'somestuffyoudontwant*' \
-V "VolumeID" .

 

[Paul]

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/linux/library/l-cdburn/index.html

(OK, now we're getting some where.)

http://cdrecord.berlios.de/private/man/cdrecord/index.html

http://cdrecord.berlios.de/private/man/cdrecord/cdrecord.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/man/cdrecord/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 ass.
It means some things I used to be able to do in Linux, I can no longer
do.

Paul