Re: ProDOS' Block Index Question

[Rubywand <rubywand@swbell.net>]

Bryan Parkoff writes ...
> 
 ....

> 
>     ProDOS has root directory that contains 51 files maximum.  This root
> directory has only one Block Table.  If root directory is destroyed or wiped
> by Disk II's hardware failure.  There is only one way to rebuild root
> directory from scratch is through Block Table.

      According to the ProDOS manual, that's pretty close. ProDOS uses 4 blocks
(2-5) for the Volume Directory. The first 4 bytes in each directory block are
used for 2-byte pointers. The first pointer points to the previous block in the
directory; the second pointer points to the next block in the directory. If
there is no previous or next block, the value of the pointer is 0.

      39 bytes are used by the directory header. You have 2048 -8 -39 = 2001
bytes to record file entries. Each file entry is 39 bytes. 2001/39 --> space
for 51 file entries in the Volume Directory. This includes subdirectory files.

      Don't know about any "block table" for the VD. There is a table which
starts in blocks after the VD which records which blocks are in use (by setting
bits); but, that's for the whole volume.

      Files in the main directory are like files in subdirectories. The bad
thing about bombing the VD is that, as far as accessing anything on the volume
is concerned, all connections are lost-- well, whatever is bombed is
disconnected. On the other hand, the VD has relatively few entries and,
especially on a large disk, many are likely to be subdirectories.
Subdirectories are fairly easy to locate via a scan using an editor like Block
Warden.

      

>     It will be harder to find data if it is less than 512 bytes because it
> does not need Block Table.  It will be easier to find data if it is greater
> than 512 bytes because it does have Block Table.

      Generally true. If you know something about the contents of a lost file--
like, you have a listing or hex dump-- then, finding the block via a scan for
content is pretty easy. Of course, the nice thing about block tables (or "index
blocks") is that they look like block tables.



>     After I have completed reconstructing root directory that points to
> Block Table, each file needs to be renamed back to the original.  The byte
> length, original date/time, and modified date/time will be difficult to
> restore back to the original.  The byte length is not important because it
> is useful for display only.

      Byte Length could be of some importance if the file has some all-zero
blocks (is a "sparse file").  Otherwise, I don't know how vital that entry is
to ProDOS.


> It is important to make sure that "Used Block" and "Block Pointer" be restored.

      Definitely, you need to point to the file's key block. Don't know how
important "Blocks Used" is. There's probably no need to worry much about the
block allocation table. That can be fixed using ProSel; or, you can move all
your salvaged files to another disk and wipe ("erase") the one that got bombed
and, then, copy your stuff back. 

      

>     It is not so easy to find the correct name back to the original that I
> want to rename each file while I have to search filename somewhere from
> Block $0008 throughout $FFFF.  I do not talk about subdirectory, but it is
> only filename.  Filename is really data that tell ProDOS to read data sector
> where filenames are stored.
 ....

      If only the Volume Directory is bombed, all of the file info in
subdirectories will be fine. Only the info for files in the VD needs salvaging.
If VD block pointers are messed up, those will need repairing, too.

      As you say, scanning should help with reconstructing filenames. For sure,
it will help with locating subdirectories and subdirectory names. Programs
which use the lost files will include references to ".txt", ".bin", etc. names.
Often, you will be able to tell which file goes with a name by its content.

      You can always assign a temporary name for files you can't identify.
Eventually, some program will give you an error and you will be able to see
what file it's looking for and adjust a name.
      


>     Is it true that Block Table always contains 7, 9, A, B, C, D, E, F, etc.
> Block $0008 is Block Table.  Block $7, $9, $A, etc are data.  Is it possible
> that Block Table can be like 7, 9, C, F, A, D, E that it is not in the order
> because it may be too fragmented?
> 

      Yes. A block table or "index block" can contain nearly any block numbers
in any order.



Rubywand