Re: Questions about cdrtools-2.01a33
me > > > > cdrecord: Future versions of cdrecord may have different drive dependent defaults.
Joerg > > > RTFM
me > > your reply does not help me at all.
Joerg > I did write this to the mailing list and in the cdrtools source
> directory. I have no time to do again.
> The future plans have been published, so what is your problem?
I am too dumb to find them. Isn't that enough of a problem ?
The remedy would be a link, a search key or a quote.
It is not my intention to be annoying. My motivation is to learn
about application problems with CD-RW in time - before my users have to.
I still did not really find what i am looking for. (Is -sao the possible
new default or will it be -raw ? Why the decision to put in question
the default mode at all ? Is new hardware upcoming which needs that ?)
Whatever, i respect your right to do cdrtools your way. I neither demand
any justification nor do i want to post unqualified criticism.
I am just curious and i am not shy to expose myself as insufficiently
educated. I also will be glad to apologize for my dumbness after having
been pointed to the spot in the docs or after having been faced with
a quote which answers my questions.
me > >What interests me most :
> >Will future default modes still allow piping of data into cdrecord ?
Joerg > man cdrecord
> man mkisofs
> There are examples.....
I read in man cdrtools-2.01/cdrecord/cdrecord.1 (of 2.01a33) :
mkisofs -R /master/tree | cdrecord -v fs=6m speed=2
That is quite exactly what my software did to produce the warning
about future defaults :
mkisofs ... | \
cdrecord -v padsize=128k fs=8m -eject driveropts=burnfree \
speed=12 dev=0,0,0 -
I tried the example literally (with dev=0,0,0) and it does produce the
warning message "cdrecord: No write mode specified.".
So i can hardly assume that this example contains my answer.
" To handle drives that need to know the size of a track
before starting to write, first run
mkisofs -R -q -print-size /master/tree
and then run
mkisofs -R /master/tree | cdrecord speed=2 dev=2,0
This could be related to my questions. I never experienced such
a drive. None of my users did, either. At least they did not bother
to tell me.
Whatever, if i understand the example right, such a drive would not
be any better suitable for on-the-fly recording if i added option -tao.
" If you like to write from stdin, make sure that cdrecord
is called with a large enough FIFO size (e.g. fs=128m),
reduce the write speed to a value below the read speed of
the source drive (e.g. speed=12), and switch the burn-
free option for the recording drive on by adding
I do follow these hints in general (with a more modest fs value).
The only other example about piping into cdrecord is about cdda2wav
which is of less interest for data backup purposes.
Joerg > and then Linux is definitely not the right OS for you.
I'm on Linux because SuSE and Redhat are the Unix of our times.
I would still be willing to live with Domain/IX if i could get
it for a modern PC with modern peripherals. I would have switched
from SunOS to Solaris if the german salesforce of Sun wouldn't have
demanded 2000 $ for a C compiler (IDE included but not needed).
I was glad to have Linux 0.99 as PC OS after NT's POSIX support proved
to be a marketing lie and SCO's C compiler demanded me to simplify my
program. When my SparcStation finally died, i found friendly asylum
on Linux PCs. First DLD, now SuSE. Sigh.
I'm not the most talented sysadmin. Usually i program my
way around any difficulties which i cannot solve directly.
I want a reliable multi-tasking multi-user system. Not more.
(My half-hearted apologies for getting off topic.)
me > > if they do not react on you - do you think they'll react on me ?
Joerg > Ask the Linux kernel trolls.
> Are they trolls?
Linus et al. once saved my job and the jobs of my friends.
You, Joerg, made my data safe during the last five years.
I will not call any of you great people names.
Not as long as i do take so much advantage from your work.
Have a nice day :)