Re: Boot block problems

[dempson@atlantis.actrix.gen.nz (David Empson)]

In article <awerner-1906960822470001@bullhead.execpc.com>,
Andrew Werner <awerner@execpc.com> wrote:
> I damaged several sectors in tracks 0 and 1 of one of my 5 1/4 disks,
> which had a LOT of work on it.  Whenever I tried to boot it, the drive
> only spun, and I didn't even get the ***** UNABLE TO LOAD PRODOS *****
> message.  I then verified the disk using Copy ][+, and found errors in
> sectors 0 and 1.

I'm not sure whether these refer to physical sector numbers or logical
sector numbers.  If they are physical sectors, then they correspond to
the first half of ProDOS blocks 0 and 4.  Block 0 contains the boot
code, which explains why it didn't boot.  Block 4 is part of the root
directory.

> After finding the aforementioned errors, I knew that I would have to
> recopy parts of PRODOS and the boot blocks.  I did so, copying tracks 0
> and 1 off of the Copy ][+ disk and onto the other disk.

Oh dear.  I'm afraid you have just destroyed all directory information
for the root directory on the disk, the volume bitmap (indicating
which blocks were used on the disk) and the contents of the first nine
data blocks on the disk, which may have contained subdirectory blocks,
file data and/or file index blocks (used to locate the data sectors).

You seem to have confused DOS 3.3 and ProDOS disk organisation.  DOS
3.3 is stored on the first three tracks of each bootable disk, with the
catalog information about half way through the disk.

With ProDOS, the boot code, root directory and volume allocation
bitmap are stored on track zero (with one block free), while PRDOOS
itself, if present, is just a normal file, which might be stored
anywhere on the disk.  If you copy PRODOS onto the disk before doing
anything else, then it will occupy the first few blocks of the disk.


Before doing ANYTHING else with this disk, make sure you write-protect
it (so you can't do any further damage by accident while trying to
repair it), and take a backup copy (use a sector-based disk copy, NOT
a file copy).  You should then attempt to repair the backup, and don't
touch the original until you are satisfied that the backup has been
recovered as far as possible.  If something goes wrong during the
recovery, you can take another copy from the original disk.

Repairing damaged disks is not an easy operation.  There are commercial
utilities which can do most of the work, but you will probably need to
do some additional work with a block editor to recover as much as
possible.

If I was doing this, I would proceed as follows.

- Use FIXCAT (part of Bag of Tricks 2, which is still being sold by
  Byte Works) to do the initial repair.  "Mr Fixit" (part of Prosel)
  would be another option, but I've never used it.

  (Note: it is not safe to run FIXCAT over a disk used with GS/OS,
  because it doesn't know about the ProDOS file system extensions for
  lower-case file names and resource forks.  Resource forks will be
  destroyed by FIXCAT.  Mr Fixit may be able to handle them, provided
  you use a new enough version.  Recent versions of Prosel-16 are the
  safest option here.)

- In FIXCAT, choose the option to start the repair operation from scratch.
  No attempt should be made to use the existing directory, because it is
  totally wrong.

- Tell FIXCAT to search the disk for lost subdirectories.  It should
  be able to locate all three subdirectories, but it won't know what
  they are called.  You can give them temporary names and examine their
  contents later to find out which directory is which.

  This step will recover all files in the subdirectories, with all of
  their directory information (filename, filetype, size, etc.) intact.

- Tell FIXCAT to search the disk for lost files.  This will probably
  recover PRODOS and BASIC.SYSTEM.  It might not be able to recover
  STARTUP and HIDRAW.VARS if they are one block files (if they are
  three or more blocks, then there is an index block which is easier
  to identify).

  For all of the files recovered at this stage, all directory information
  will have been lost - the filename, filetype, exact size (in bytes) and
  auxiliary type.  The only information that can be recovered
  automatically is the number of disk blocks used.  You should be able to
  work out which file is which from this.

- FIXCAT will then write out a repaired root directory and volume bitmap,
  and the disk should now be usable.

- To tidy things up, I would next use ZAP (another tool in Bag of
  Tricks 2) to examine the recovered root directory files to attempt to
  identify their exact length.  This is reasonably easy for a BASIC file,
  but I don't know what internal format is used by a VAR file.  The length
  should be patched straight into the root directory (this requires
  reference documentation on the directory format).

  If these files were not recovered automatically, it would be
  necessary to manually search all unused disk blocks to try to locate
  them.

- I would then rename all the files as appropriate, and go through
  each file and check that it appears to be OK.

Finally, I would copy the backup disk back onto the original (using
track or sector copy, just for speed this time).

I suggest that you delete the recovered PRODOS and BASIC.SYSTEM files,
and copy them onto the disk again (using file copy, _not_ track or
sector copy).

Since launching UTIL.SYSTEM is actually running BASIC.SYSTEM, this
means that you have a pretty good chance that the overwritten data
blocks are all part of the PRODOS file.  This will be the case if
PRODOS was the first file you copied onto the disk after it was
formatted.

If the copy of PRODOS on the Copy II+ disk was a different version,
then you have a somewhat damaged file anyway, which is a combination
of the two versions.


If the above procedure seems complicated, then consider it a lesson in
making regular (or even irregular) backups of important data, and not
trying to repair disks when you are unfamiliar with the file system's
internal organisation.  If you had posted a query here when you had
discovered that sectors 0 and 4 were damaged, then it would have been
possible to repair the disk without risking anything.

If you think that you will not be able to manage the repair yourself
(or you don't have the necessary software), I suggest that you try to
find a nearby Apple II expert, or send the disk to someone who will
repair it for you.


Footnote: as you will note from the repair process, it is MUCH easier
to recover files that have been stored in subdirectories when the root
directory has been damaged.  Important files should always be placed
in a subdirectory if you want to improve the chances of recovering them
fully.
-- 
David Empson
dempson@actrix.gen.nz
Snail mail: P.O. Box 27-103, Wellington, New Zealand