Problems RH won't fix

[Nifty Hat Mitch]

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 at herakles.homelinux.org 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.