On Thu, Dec 09, 2004 at 08:56:55AM -0800, Brian T. Brunner wrote: > > Grab the source for mkisofs, fix it, and submit the patch. > Gark top posting makes it hard for more than three replies to make sense in a group like this. .... > > >>> debian@xxxxxxxxxxxxxxxxxxxxxx 12/08/04 01:37AM >>> > I am surprised at some of the bug RH thinks are unimportant. Take this > segfault in mkisofs: > https://bugzilla.redhat.com/beta/show_bug.cgi?id=141093 > > This arises because mkisofs doesn't properly check its parameters. > > Another bug I filed because mkisofs in some circumstances modifies the source > tree, While this is documented behaviour, it seems to me that this is just > plain wrong. It's not what a user should expect, and in the particular > cicumstances in which I found it, it's impossible. > > What do others think? > Tough one. This bug apparently does not pass my newly invented "garbage in -- no garbage out" test. i.e. if you pass garbage to the program it does not appear to silently generate more garbage. And, at least the output can be inspected and verified by mounting it loopback (diff -r). If you test the exit status of the mkisofs invocation you should be getting an error and not a junk file. Having said this when a program dumps core or barfs Null-Pointer there is no help to the poor user that is attempting to make things work. This "Buzzz-Bad Try Again" behavior sux big lumpy rocks for most folk. I would Google up some correct invocations then go back to the original and pick a specific input and flag as a problem. I sort of think that the problem is with your -x option, but, since the man page says "NOTE: The -m and -x option description should both be updated, they are wrong." you will find getting the old lumpy behavior it to be more robust difficult. I am going to pick on the -x argument by way of discussion. A more productive bugzilla might note that arguments like: -x ./isolinux -x ./lost+found cause the program to emit the cryptic "mkisofs: Error: (NULL POINTER)". A better error might be to test for the Null Pointer then exit with a message "mkisofs: Error: bad -x arg". Then state that a fully qualified path name works. i.e. make it 'more clear' how to focus the effort. -x /tmp/lost+found i.e. Be very specific about the error so the engineer only needs to fix something very specific. A specific "null pointer test" is easy to code while a full input argument test could take weeks. I am with you that errors like this are bugs. I am also with the engineer that closed this. No case to fix it other than "operator error" generates an error was made. SUMMARY: In such cases you need to be very specific and yes this it the open source world: Grab the source for mkisofs, fix it, and submit the patch. And, if you are not a 'c' programmer use a group like this to make it very easy for one of the programmers/ debuggers here to help. -- T o m M i t c h e l l spam unwanted email. SPAM, good eats, and a trademark of Hormel Foods.
