> >If you make mkisofs completely "correct", it becomes rather useless.
> 
> >The default behavior of mkisofs happens to also be the default behavior of 
> >tar; that is, tar continues merrily on its way after an error (at least GNU 
> >tar does).
> 
> >There are good reasons to allow a process that takes a long time to complete, 
> >such as mkisofs, to continue after an error is encountered rather than just 
> >quit.
> 
> Every tar that works as expected does this way.
> 
> >From the 1979 tar.c:
> 
>         infile = open(shortname, 0); 
>         if (infile < 0) { 
>                 fprintf(stderr, "tar: %s: cannot open file\n", longname); 
>                 return; 
>         } 
>  
> 
> Not even a notification to the caller is done. The message is all.
> 
> 'Modern' tar implementations like star (1982-2002 ;-) print a problem
> sumary at the end....
> 
> 
> All other people who create DVDs know that files > 2 GB are a problem and avoid
> them. Even the DVD video standard wants the video to be split into several ~ 1 GB 
> files.

Then hardwire "exit 0" into mkisofs & cdrecord. No need to tell any
script (or other programs) that there has been an error. It's totaly
pointless to tell there there was an error. Everything in one go or
nothing at all, there is good chance that everything worked fine. I've
recorded around 200 DVD-Rs without problems. So the error percentage is
less then 1 percent. Why care for problems less then 1 percent.

No other program comes currently to my mind where i need output-parsing
to get the notice of a FATAL error. (You know that the "file too big"
means that at least half of the content (seen from the size point) is
missing from the image? And in my eyes thats a FATAL error. Maybe i
should do it the other way around and place a filesize checker into my
image-creation script, but why should i do that hassle when mkisofs
could just throw an error?)





Bis denn

-- 
Real Programmers consider "what you see is what you get" to be just as 
bad a concept in Text Editors as it is in women. No, the Real Programmer
wants a "you asked for it, you got it" text editor -- complicated, 
cryptic, powerful, unforgiving, dangerous.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Reply via email to