Re: Questions about cdrtools-2.01a33

[scdbackup@gmx.net]

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. 

Please.

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) :

"EXAMPLES
...
           mkisofs -R /master/tree | cdrecord  -v  fs=6m  speed=2
        dev=2,0 -
"
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
       tsize=XXXs -
"
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
       driveropts=burnfree.
"
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.
Shrug.

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.
Linux is.

(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 :)

Thomas