Rubywand,
Thanks...Yes...Block Table can mean Index Table. One problem is that I
don't know the filetype such as SYS, S16, BAS, BIN, and etc. Is it possible
that it is already stored in Finder.Data that has all filename information
including filetype from GS/OS 6.0.1?
--
Bryan Parkoff
"Rubywand" <rubywand@swbell.net> wrote in message
40326707.23FF824F@swbell.net">news:40326707.23FF824F@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