Subject: while we're looking at old bugs
To: None <current-users@NetBSD.ORG>
From: John F. Woods <>
List: current-users
Date: 09/30/1997 16:05:23
Three of mine are still outstanding, one dating back to NetBSD 1.0A.

bin/1223 complains that if you move a file that you don't own between
filesystems, mv prints a warning about the failure of the chown() to
reset the file ownership.  This confuses novices and fills news log
files with useless fluff.  Reasoning from the wording of the mv(1) and
cp(1) manual pages, I think the message is inappropriate and should be

There seems to be no sign that anyone has examined this bug or
considered the patch (which is essentially to take error message code
from cp and to put it into mv).  I'd argue that this bug is a perfect
example of the "perfectly good patches sit around forever" (or for two
years, whichever comes first); the patch is straightforward, and
either the motivation is bogus (in which case it should be closed with
a "yer full of it" comment) or it's valid (in which case this code is
either wrong in cp or it's right as a patch).

kern/3021 describes poor handling of UNIT ATTENTION in the scsi
driver.  The sense code handling recently got churned, but I don't
think this has been changed.  At any rate, the bug doesn't seem to
have been looked at.  (This one includes only skeletal code.)

kern/3022 complains that the handling of extended sense information
was completely wrong.  The recent SCSIVERBOSE changes have almost
fixed this entirely:  the driver still (in the SCSIDEBUG code) prints
out extra_len bytes worth of junk starting at extra_bytes[], which is
wrong (the extra_len count (Additional Sense Length) starts at the 
Command-Specific Information field, several bytes back from where
extra_bytes[] starts).  If someone would please change

		for (count = 0; count < sense->extra_len; count++)
			printf("0x%x ", sense->extra_bytes[count]);
		for (count = 0; count < sense->extra_len; count++)
			printf("0x%x ", sense->cmd_spec_info[count]);

(or something more tasteful if you don't want to rely on addressing
off the end of cmd_spec_info!), this report should be closed.