🚀 go-pugleaf

	What happens when you SetComment() a comment that is larger than
the field can hold on the file inode?  In my case it created a spectacular
crash when I got a directory after doing the SetComment() (which worked).

	*C-R-A-S-H*, reboot (asked for kickstart, in fact), chug chug chug,
disk-validator run run run.  ok, all done.  

	cd to the directory, Dir .... *C-R-A-S-H*, reboot chug chug chug ...
no disk-validator this time.  Hmmm.... Time for DiskED

	DiskED:  search through and find the directory.  Look at the hash
table, find the file in question.   "GEE, it looks like the filesystem
blithly copied the too-large comment out into the filename and remaining
fields of the file header!" (actually, my exact words were more colorful).

	Well, that is what caused the first crash ... totally destroyed
checksum and whatever other fields are at the end of a file header.  The
disk validator fixed the checksum and those fields, but DID NOT fix the
filename!  Not only was the BCPL length of the filename x67, but now the
hash value was all wrong (of course) and thus Delete could not delete it.

	Ok, modify the filename to "A" (0165), move the file header pointer
in the directory's hash table to the right place and delete the file.  Back
to normal.

	(1) SetComment() shouldn't let you do that.
	(2) The Disk-Validator should check for impossible filename lengths,
	    but more especially, should make sure the HASH VALUE corrosponds
	    to the filename.

	P.S.  Good Job to C-A on the 1.3 enhancer kit!  I like the revised
autodocs and the printer driver examples!

					-Matt