> >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]