[Coco] Question about Chris Burke's ba and bd commands

[Gene Heskett]

On Monday 08 October 2012 10:01:44 Chester A Patterson did opine:

> It is my understanding that the B&B commands will cause unsavory and
> wicked damage to any drive not standard cluster.  However I write this
> without a personal background of technical saavy but from the
> discussion to a similar question posited here some time ago vis a vis
> the B&B OS9 DEFRAG command.

I was afraid of that.  Sigh.  I ran it to fix one sector, and it didn't fix 
the sector I told it to, hence the question.

Re defrag:  While this and repack are both good ideas, it is best to 
prevent the fragmentation in the first place, something I have preached 
about in the past, at length even:

The typical disk descriptor has 'sas' set to 8, which IMO should have been 
at least $20 from the gitgo.  That would prevent the huge majority of the 
fragmentation we have had.  And for copying really big files, setting it 
temporarily to $FF is a great idea.  If that allocation fails, then check 
the size of the file you are trying to move and determine how many sectors 
it would need, add 2 (one for the FD sector, one for the end of the file 
rounding up) and set sas to that.  If that fails to allocate, there isn't 
room on the disk to copy it in one FD.SEG entry anyway.

Justification: Yes, os9/nitros9 will allocate that much ($FF?) when it 
opens the file for write.  But when it has finished the copy, the 
allocation is then trimmed to what the file actually occupied and that 
sector of the FAT rewritten for the second time by the close command.
IOW, there isn't any valid reason to use the smaller value of sas that 
winds up breaking any file up into 2048 bytes times cluster size on the 
media surface.  It simply makes no sense.

You can do this in memory with dmode, or you can fix the descriptor in the 
OS9Boot file with dEd if you are comfy with that, making that change 
permanent as long as you are using that boot disk.

Or you can dmode the descriptor in memory and then 'save' it, and use that 
one in the next incarnation of your mb command by editing the bootlist to 
use the saved version.

If you are comfortable with dEd, its easier (to me) to fix the descriptor 
in the boot disks OS9Boot, don't forget to v(erify) it, close ded and press 
the reset button to reboot from the same but now fixed disk.

Looks like another challenge project to me, sort of like vfy was at the 
time.  If & when I have something that seems to work, I'll put it on my web 
page and announce it here.  But don't hold your breath, it might take a 
while as I've got to first learn the math to do it right.

However, something Robert G. suggested is being checked out right now, and 
may turn out to be an equally viable way to fix things too.  Yes, it 
worked!

Procedure:

When a disk gets a bad FAT, first use ded /diskname@ to set enough FF bytes 
in the fat starting LSN1 to cover the area used by files on the disk.

Run:
dcheck -mpw=/SomeOtherDisk /diskname >BigEnoughLocationToHoldA20megfile

When done, list the file, looking for Previously allocated sectors and find 
out which directory entry of the two conflicting entries is the correct 
one, and, using ded to zero the first character of the bogus directory 
entry.  Repeat until a rerun of dcheck as above reports that the structure 
is "intact"

At this point, you will have, in /SomeOtherDisk/dcheck030, a file that may 
be too long but which contains an image of a correct FAT.

Now call up a session of Basic09 and hit 'e dd'
Using the editors 1 space leader, enter
 DIM buffer(256):BYTE
 DIM ipath,opath:BYTE
 DIM count:REAL
 DIM iname,oname:STRING[32]
 INPUT #1,"sourcefile:",iname
 INPUT #1,"destination device:",oname
 OPEN #ipath,iname:READ
 OPEN #opath,oname:WRITE
 SEEK #opath,256
 count=0
 WHILE count < size_of_FAT_minus_1 DO 
 GET #ipath,buffer
 PUT #opath,buffer
 count=count+1
 PRINT count
 ENDWHILE 
 CLOSE #opath
 CLOSE #ipath
 PRINT 
 PRINT "bytes written:"
 count=count*256
 PRINT count
 END 

Now, without the leading space, hit q & enter which should put you back at 
the Basic09 prompt.  Congratulations, you are now a basic09 programmer!

type 'run'

It will ask you for the name of the source file, in this case the path to 
that dcheck030 you told dcheck to save with the -mpw option above.
Hit enter there.
It will next ask you for the destination device, /dd@, /s1@, /dh@, whatever 
but you must use the @ ending character as shown.

Knowing my FAT was clean beyond about the 20th sector, that is all I copied 
over.  The result then of a confirming run of dcheck is:

{t2|07}/DD:list clusterlist.txt

Volume - 'hesketts-other-big-disk' on device /dh
$EDDD bytes in allocation map
4 sectors per cluster
$1DBB90 total sectors on media
Sector $0000EF is start of root directory FD
$00F8 sectors used for id, allocation map and root directory
Building allocation map work file...
Checking allocation map file...

'hesketts-other-big-disk' file structure is intact
578 directories
12981 files

Which is the target of about 4 days worth of running dcheck at up to 2.5 
hours a session.  Whew!

I have other recovery work to do yet, but at least the disk is safe to 
write to.  The count of files above is off, by 100 or more.  Hopefully, 
they exist on the other drive, so a cross copy by dsave should be able to 
restore the huge majority of the missing files.

Since the two drives are identical except for their formatting and 
partitioning, I hope to be able eventually to use a variation of the above 
program to clone the failing drive (stiction problems) to the other, thus 
preserving even the HDBDOS partitions beyond the 498 meg os9 partition.

Question:  Does anyone here have a full (SDv2.1) definition of all 8 bits 
of the descriptors dns byte when the typ byte indicates it is a hard drive?

They are NOT in our publicly available rbfdefs files.  What I can find only 
defines 2 of the 8 bits, and neither of those defines can explain why 
format went after the wrong drive, starting this whole (insert a minute or 
more monologue of swear words here) fiasco in the first place. :( :( :(

Suffice to say, the 'drv' byte in the descriptor does NOT guarantee that if 
set to 01, it will actually access drive #1 on the scsi bus.

[...]

Cheers, Gene
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
My web page: <http://coyoteden.dyndns-free.com:85/gene> is up!
* UNIX is a Trademark of Bell Laboratories.