home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Club Amiga de Montreal - CAM
/
CAM_CD_1.iso
/
files
/
144.lha
/
disk.tutor
< prev
next >
Wrap
Text File
|
1986-11-21
|
47KB
|
969 lines
An Explanation of AmigaDOS Storage Device Structure
In order for you to use a disk editor to its full disk-saving/disk-altering
potential, you must first understand the structure of an AmigaDOS device.
References will be made to a P.D. disk editor called 'Sectorama', though the
basic information and principals presented in this doc will be applicable to
all disk editors. Note that to avoid confusion and to provide immediately
applicable info, the block formats presented in this doc are specifically for
512 byte blocks. For larger blocks, the size of the Hash Table will vary and
all info after the hash table will be displaced ahead of the hash table so
the secondary-type word is at the end of the block. All devices I know of to
this point use a 512 byte block.
This document is basically written in two parts. The first part is an
explanation of what each word in each type of block, how various types
of blocks are structured, and how all these blocks relate to one another on
an AmigaDOS storage device. The second part is an explanation of how to do
things with a disk editor such as sectorama.
I) BLOCK BASICS
============
Generally, each block on an AmigaDOS device contains a checksum, a header
key whose value is the disk address of the block, and a block type which tells
you what type of block this is so you know what format that particular block
uses. Note that when I use the term, 'block', I am referring to a 512 byte
chunk of storage space on an AmigaDOS device. For example, on a floppy or
hard drive, a block refers to a 512 byte sector. In VDO: and RAM:, a block
refers to 512 contiguous bytes somewhere in memory. Also note that the size
of each datum in a block is a 32 bit word. For all blocks, the first
six words are as follows:
+--------------------+
0 | Block Type |
+--------------------+
1 | Header Key |
+--------------------+
2 | Number or count |
+--------------------+
3 | Table or Data size |
+--------------------+
4 | First or next data |
+--------------------+
5 | Checksum |
+--------------------+
: :
Block Type - This identifies the general size and structure of this block.
It currently has one of three values:
T.SHORT = 00000002 This indicates the block is at the head of
a list (i.e. a HEADER BLOCK).
T.LIST = 00000010 This indicates the block is a LIST BLOCK.
A list block is a member of a linked list
list blocks and contains a table of pointers
to data blocks.
T.DATA = 00000008 This indicates the block is a DATA BLOCK.
A data block is simply a block that contains
data and will be described later in this
doc.
Header Key - This 32-bit word is the device's address for this block. It
is a pointer to this block.
Number or Count - If this not a data block, this is a total count of data
blocks (and, hence, the highest sequence number of any
data block) pointed-to by this block.
- If this block is a data block, this number is the sequence
number of this data block. That is, it tells us this data
block is the n'th member of a list of data blocks.
Table or Data Size - This is a count of how many 32-bit words there are in
the table or data starting at word # 6 in this block.
First or Next Data - This is a pointer to the data block following this block.
If this block is a header or a list block, then this
pointer will point to the first data block in a list
of data blocks.
Checksum - When this number and the values of all other words in this block
are added up, the sum must be zero. This is how bad blocks are
detected by AmigaDOS.
For all types of blocks excepting data blocks, the last four words have the
following format:
: :
+----------------+
7C | Hashchain |
+----------------+
7D | Parent |
+----------------+
7E | Extension |
+----------------+
7F | Secondary Type |
+----------------+
Hashchain - points to the next entry on this hash chain.
Parent - pointer to the parent directory. The parent directory is the
directory block which either points to this block or points to a
linked list (i.e. hash chain) of which this block is a member.
Extension - pointer to the next extension block which essentially extends the
table which starts at word # 6 of this block.
Secondary Type - This exactly identifies what kind of block this is. This
tells us exactly what function and structure this block has.
The possible codes in this word are:
ST.ROOT = 00000001 This identifies the ROOT BLOCK, which
is the device's 'root directory'.
This block ultimately points to all
the files and directories on the
storage device.
ST.USERDIR = 00000002 This identifies a USER DIRECTORY BLOCK
which points to all the files and
directories which have been defined
for this directory.
ST.FILE = FFFFFFFD This identifies either a FILE HEADER
BLOCK, if the block type at word # 1
is T.SHORT, or a FILE LIST BLOCK if
the block type is T.LIST.
A FILE HEADER BLOCK points to all the
data blocks that make up the file. If
there are too many data blocks to be
pointed to by this block, a list of
FILE LIST BLOCKS is pointed-to by the
extension pointer at word # 7E. A
FILE LIST BLOCK simply extends the
table and points to the next FILE LIST
BLOCK if more data block pointers are
required.
Note that the above-mentioned word definitions are not applicable to some
block types and functions. Where their function is non-applicable, their
value is usually set at zero.
II) THE ROOT BLOCK
==============
The block that ultimately points to everything on the disk is called the
'Root Block'. This block usually resides in the exact center of a storage
device to minimize the distance a read/write head of a floppy or hard disk
must move when travelling from an outer cylinder to the Root Block. The
format of the Root Block is as follows:
symbolic usual
value value
+----------------------+
0 | T.SHORT = 00000002 | Indicates this is a 512 byte header block
+----------------------+
1 | 0 = 00000000 | Header Key (Always zero in a root block)
+----------------------+
2 | 0 = 00000000 | Highest sequence number in chain (0 for root)
+----------------------+
3 | HT SIZE = 00000048 | Hashtable size (=blocksize-56 = 512/4-56 words)
+----------------------+
4 | 0 = 00000000 |
+----------------------+
5 | CHECKSUM = ? | Checksum for this block
----+----------------------+
{ 6 | |
{ | Hash Table |
{ to : :
{ : :
{ 4D | |
----+----------------------+
4E | BMFLAG = FFFFFFFF | True (all F's) if device or disk bitmap valid
----+----------------------+
{ 4F | |
{ | Bitmap Pages |
{ to : :
{ : :
{ 68 | |
----+----------------------+
69 | DAYS = ? | Volume last altered date and time.
+----------------------+ Date is in packed format.
6A | MINS = ? | Time is rated in minutes and ticks.
+----------------------+ One tick is 1/60th of a second.
6B | TICKS = ? |
----+----------------------+
{ 6C | | Volume name as a BCPL string of 30 characters
{ | Disk Name | or less, though the amount of space to store
{ to : : this string always remains the same size.
{ : :
{ 78 | |
----+----------------------+
79 |CREATEDAYS = ? | Date and time when this volume was created.
+----------------------+ Format here, as well as all date/time data
7A |CREATEMINS = ? | presented in other types of blocks are in the
+----------------------+ format shown for the above volume last altered
7B |CREATETICKS= ? | date and time.
+----------------------+
7C | 0 = 00000000 | Next entry on this hash chain (0 for root)
+----------------------+
7D | 0 = 00000000 | Parent directory (always 0 for root)
+----------------------+
7E | 0 = 00000000 | Extension (always 0 for root)
+----------------------+
7F | ST.ROOT = 00000001 | Secondary type indicates this is a Root Block
+----------------------+
-> What the heck is a HASH TABLE?
A HASH TABLE is a table of pointers to files and to lists of files. To
locate a particular file in the table, the name of the file is used to
calculate where in the table it is to be located. This location may not be
unique to the name of this file. In this case, the pointer will point to a
linked list of file headers which must be traversed until the file header for
the file we're searching for is found. This linked list is referred to as a
HASH CHAIN.
The actual searching-out of files will be discussed in more practical terms
in the practical portion of this document.
-> What things are pointed-to by pointers in a HASH TABLE?
Each non-zero pointers in the hash table points to either a FILE HEADER
BLOCK or a USER DIRECTORY BLOCK which, in turn, may have a hash chain pointer
which will point to the next file header block or user directory block in
the hash chain.
-> What are bitmap pages?
The words in the list of bitmap pages point to 512 byte blocks which
simply map-out which blocks on the device are used, and which are free for
usage. I don't yet understand how the bitmaps are set-up or maintained,
but as soon as I find out, I'll slip the info into this document.
-> What is a BCPL string?
This is a string of bytes where the first byte indicates the number of
characters in the string (say, 'n' characters), the next 'n' characters
contain the ASCII values for the string, and the rest of the string is
ignored. For example, on my Workbench disk, a hex dump of the string looks
like this:
09576F72 6B62656E 63686F72 6B62656E .Workbenchorkben
63680000 00000000 00000000 00000000 ch..............
00000000 00000000 ........
Where the 09 at the beginning specifies that only the next nine characters
are valid characters of the string and the rest are ignored.
Note that for the root block, zeros are always in the Header Key, Sequence
Number, Hash cain, Parent, and Extension fields. This is because a ROOT BLOCK
is always at a specific spot on the device (for a disk, it is exactly
cenetered between the outer- and inner-most cylinders), it never require hash
table extensions, it is not pointed-to by a hash table and is not part of a
hash list, and it does not have a parent directory.
III) USER DIRECTORY BLOCKS
=====================
A user directory block is created when a new directory is made in a storage
device. It contains its own name and protection status, its parent directory,
as well as a hash table pointing to files and user directories that have been
placed into this directory. The hash table functions exactly the same way as
that in the ROOT BLOCK. The format of a USER DIRECTORY BLOCK is as follows:
symbolic usual
value value
+----------------------+
0 | T.SHORT = 00000002 | Indicates this is a 512 byte header block
+----------------------+
1 | OWN KEY = ? | Header Key (pointer to this very block)
+----------------------+
2 | 0 = 00000000 | Highest sequence number in chain (always zero)
+----------------------+
3 | 0 = 00000000 |
+----------------------+
4 | 0 = 00000000 |
+----------------------+
5 | CHECKSUM = ? | Checksum for this block
----+----------------------+
{ 6 | |
{ | Hash Table |
{ to : :
{ : :
{ 4D | |
----+----------------------+
4E | SPARE = 00000000 |
4F | SPARE = 00000000 |
+----------------------+
50 | PROTECT = ? | Protection bits (Read/Write/Execute/Delete)
+----------------------+
51 | 0 = 00000000 | Unused (always zero)
----+----------------------+
{ 52 | |
{ | COMMENT | Stored as a BCPL string
{ to : : (up to 90 characters)
{ : :
{ 68 | |
----+----------------------+
69 | DAYS = ? | Directory creation date and time.
+----------------------+
6A | MINS = ? |
+----------------------+
6B | TICKS = ? |
----+----------------------+
{ 6C | |
{ | Directory Name | Directory name as a BCPL
{ to : : (up to 30 characters)
{ : :
{ 7B | |
----+----------------------+
7C |HASHCHAIN = ? | Next entry with same hash value
+----------------------+
7D | PARENT = ? | Back pointer to parent directory
+----------------------+
7E | 0 = 00000000 | Extension
+----------------------+
7F | ST.ROOT = 00000002 | Secondary type (user directory block)
+----------------------+
IV) FILE HEADER BLOCK
=================
This block is the first block of any given file. It contains file
information such as the name, size, protection status, creation date, and a
pointer to the parent directory block of the file. It also contains a table
of pointers to all the data blocks that make up the file. If there are more
data blocks than there are pointers in the table of data block pointers (at
words # 6 to 4D), an extension pointer is provided to a FILE LIST BLOCK which
contains a similar table of data block pointers. If the file list block
still doesn't provide enough pointers, it will provide yet another extension
pointer to another FILE LIST BLOCK. This list of FILE LIST BLOCKS extends
until enough pointers are provided to point to all the data blocks of the
file.
symbolic usual
value value
+----------------------+
0 | T.SHORT = 00000002 | Indicates this is a 512 byte header block
+----------------------+
1 | OWN KEY = ? | Header Key (pointer to this very block)
+----------------------+
2 |HIGHEST SEQ= ? | Number of data blocks pointed-to by this block
+----------------------+
3 |DATA SIZE = ? |
+----------------------+
4 |FIRST DATA = ? | Pointer to the first data block of the file
+----------------------+
5 | CHECKSUM = ? | Checksum for this block
----+----------------------+
{ 6 | : |
{ : : : List of pointers to data blocks
{ to : : : (i.e. Data block keys)
{ | DATA BLOCK 3 |
{ | DATA BLOCK 2 |
{ 4D | DATA BLOCK 1 |
----+----------------------+
4E | SPARE = 00000000 |
4F | SPARE = 00000000 |
+----------------------+
50 | PROTECT = ? | Protection bits (Read/Write/Execute/Delete)
+----------------------+
51 | BYTESIZE = ? | Total size of file in bytes
----+----------------------+
{ 52 | |
{ | COMMENT | Stored as a BCPL string
{ to : : (up to 90 characters)
{ : :
{ 68 | |
----+----------------------+
69 | DAYS = ? | File creation date and time.
+----------------------+
6A | MINS = ? |
+----------------------+
6B | TICKS = ? |
----+----------------------+
{ 6C | |
{ | File Name | File name as a BCPL string
{ to : : (up to 30 characters)
{ : :
{ 7B | |
----+----------------------+
7C |HASHCHAIN = ? | Next entry with same hash value
+----------------------+
7D | PARENT = ? | Back pointer to parent directory
+----------------------+
7E |EXTENSION = ? | Pointer to a FILE LIST BLOCK (if required)
+----------------------+
7F | ST.ROOT = FFFFFFFD | Secondary type (file header block)
+----------------------+
V) FILE LIST BLOCK
===============
This type of block is used to extend the table of data block keys
(pointers) of a FILE HEADER BLOCK when the table in the FILE HEADER BLOCK
hasn't enough pointers to point to all the file's data blocks. If a FILE
LIST BLOCK doesn't have enough pointers to point to the rest of the file's
data blocks, the EXTENSION pointer of the block will point to yet another
FILE LIST BLOCK. The extension list continues until enough pointers are
provided for all the data blocks in the file.
symbolic usual
value value
+----------------------+
0 | T.LIST = 00000010 | Indicates this is a file list block
+----------------------+
1 | OWN KEY = ? | Header Key (pointer to this very block)
+----------------------+
2 |BLOCK COUNT= ? | Number of data blocks pointed-to by this block
+----------------------+
3 |DATA SIZE = 00000000 |
+----------------------+
4 |FIRST DATA = 00000000 |
+----------------------+
5 | CHECKSUM = ? | Checksum for this block
----+----------------------+
{ 6 | : |
{ : : : Extended list of pointers to data blocks
{ to : : : (i.e. Data block keys)
{ | DATA BLOCK 3 |
{ | DATA BLOCK 2 |
{ 4D | DATA BLOCK 1 |
----+----------------------+
{ 4E | |
{ | unused | unused (all zeros)
{ to : :
{ : :
{ 7B | |
----+----------------------+
7C | 0 = 00000000 | Next in hash list (always zero for list block)
+----------------------+
7D | PARENT = ? | Points to the file header block of this file
+----------------------+
7E |EXTENSION = ? | Points to the next FILE LIST BLOCK (if required)
+----------------------+
7F | ST.ROOT = FFFFFFFD | Secondary type (file header block)
+----------------------+
VI) DATA BLOCK
==========
A data block contains data from a file and is pointed-to by preceding
data blocks and by a pointer in a table in either a FILE HEADER BLOCK or a
FILE LIST BLOCK. Thus, the data block can be accessed directly from a header
or list block of a file, or sequentially by following the linked list of data
blocks. Each data block also points to the FILE HEADER BLOCK which describes
the file which contains this data block. A sequence number is also present
in a data block, and indicates that this data block is the n'th data block
in the list of the file's data blocks.
symbolic usual
value value
+----------------------+
0 | T.DATA = 00000008 | Indicates this is a data block
+----------------------+
1 | HEADER = ? | Header key pointing to the file header block.
+----------------------+
2 | SEQ NUM = ? | Sequence number
+----------------------+
3 | DATA SIZE = 00000000 | Number of words of data in this block
+----------------------+
4 | NEXT DATA = ? | Pointer to the next data block
+----------------------+
5 | CHECKSUM = ? | Checksum for this block
----+----------------------+
{ 6 | |
{ | DATA |
{ to : :
{ : :
{ 7F | |
+----------------------+
VII) HOW DO THE BLOCKS FIT TOGETHER?
===============================
The ROOT BLOCK is located at a fixed location, exactly between the highest
and lowest addresses available on a storage device. The ROOT BLOCK contains
a table of pointers (the hash table) to linked lists (hash chains) of USER
DIRECTORY BLOCKS and FILE HEADER BLOCKS which describe user directories and
files accessible from the root directory.
A USER DIRECTORY BLOCK contains the name and protection status of a user
directory, as well as a hash table containing pointers to hash chains of
USER DIRECTORY BLOCKS and FILE HEADER BLOCKS which describe user directories
and files accessible from that user directory. Since the USER DIRECTORY
itself is a member of a hash chain, it also contains pointers to its parent
directory block and to the next USER DIRECTORY BLOCK or FILE HEADER BLOCK in
the header chain.
A FILE HEADER BLOCK contains information describing the file it represents,
as well as a table of pointers to DATA BLOCKS that make up the file. If
there aren't enough pointers in this table to point to all the file's DATA
BLOCKS, an EXTENSION pointer points to a list of FILE LIST BLOCKS which
extend the table. Since the FILE HEADER BLOCK is a member of a hash chain,
it contains pointers to its parent directory and to the next USER DIRECTORY
BLOCK or FILE HEADER BLOCK in the header chain.
A FILE LIST BLOCK contains a table of pointers to DATA BLOCKS and extends
the table of the FILE HEADER BLOCK or FILE LIST BLOCK which points to this
FILE LIST BLOCK. If there aren't enough pointers in this table to point to
the remainder of the file's DATA BLOCKS, an EXTENSION pointer in the FILE
LIST BLOCK points to the next FILE LIST BLOCK to extend its data block table.
A DATA BLOCK's main content is data. It is part of a linked list of DATA
BLOCKS and includes a pointer to the next DATA BLOCK in the list. It also
includes a sequence number indicating that this DATA BLOCK is the n'th DATA
BLOCK in the list. Each DATA BLOCK is pointed-to both by the preceding DATA
BLOCK in the list, and by a pointer in a data block table in either a FILE
HEADER BLOCK or a FILE LIST BLOCK. Each DATA BLOCK also contains a pointer
to the FILE HEADER BLOCK which describes the file which the DATA BLOCK is a
member of.
Confused? Don't worry, practical stuff is coming up next...
VIII) UNDERSTANDING YOUR DISK EDITOR
==============================
Before we begin playing with a disk editor, I recommend that you create a
backup of a densely populated disk, like your workbench, so that if a wrong
key is pressed while looking through the backup, you haven't done damage to
your one and only copy.
a) A Look at Sectorama
===================
For those of you lucky enough to have a copy of sectorama handy, fire it
up and I can explain what all those obscure thingies on the right side and
of the top line of the screen mean and where, from the block you are
looking at, the information was taken.
The lower right hand portion of the display identifies the storage
device currently being examined by this sectorama display. It gives us
the device name (as a volume name), the device unit number, and the
filename of the device driver that communicates with the device.
The display section immediately above this info contains hardware-
dependant information. The middle column shows us the the sector, track
cylinder, surface, and block numbers of the block currently being
displayed. This information is all given in decimal values. All these
statistics are all determined by a set of info used by the device driver.
For a floppy, for example, these tell us on which cylinder the read/write
head is currently positioned, which sector on which surface (top or bottom)
is being read by the read/write head, and the hardware-specific track and
block numbers for that sector. The rightmost column are device statistics.
These tell us how many of each category there are on this device.
Note that by pointing at any of the figures in the center column of this
section, you can change the current values. By changing sector, surface,
or block number, you can examine any sector of the device immediately.
The section immediately above the hardware information contains
information about (and from) the block currently being displayed:
Date -refers to the creation date which is taken from word # 69.
Time -is calculated from words # 6A (to get hours and minutes) and
# 6B (to get seconds).
Highest Seq # -is taken from word # 2 and refers to the number of
words used in the table starting at word # 6.
Data Size -refers to the size of the table at word # 6.
Protect -refers to the protection status of a user directory block or
a file header block and is taken from the value at word # 50
File Bytes -refers to the size of a file in kilobytes. This value is
1/1000'th the value of word # 51.
The section at the upper right corner of the display is a list of
keyboard commands with current values beside them. All except the
checksum are pointers to other blocks in the device. The checksum is the
current block's checksum value taken from word # 5. This value must be
recalculated every time you make an alteration to a block. The pointers
shown beside each command are as follows:
R-Go Root -points to the root directory of this disk. This pointer
is a constant value which has been calculate for this
storage device.
P-Go Parent -points to a FILE HEADER BLOCK's or USER DIRECTORY BLOCK's
parent directory block. This pointer is taken from
word # 7D.
C-Go Hash Chain -points to the next FILE HEADER BLOCK or USER
DIRECTORY BLOCK in this blocks hash chain. This
pointer is taken from word # 7C.
X-Go Extension -points to the next FILE LIST BLOCK in an extension
chain. This pointer is taken from word # 7E.
H-Go Header -for DATA BLOCKS, this points to the FILE HEADER BLOCK
to which this DATA BLOCK belongs.
-for other blocks, this points to the block currently
being examined.
-in both cases, this pointer is taken from word # 1.
For all the above commands, if you type the letter to initiate the
command, sectorama will jump to the block corresponding to the pointer
displayed beside the command.
At the top of the display are three more information displays. On the
left is the block number of the block currently being displayed. Next to
that is the Type of the block being displayed. The block type is
determined by word # 0, which contains the block type, and word # 7F,
which contains the secondary type.
Next to the block type is the Name of the block. This name may be a
volume name or a directory name or a file name, depending on if this block
is a ROOT BLOCK, a USER DIRECTORY BLOCK, or a FILE HEADER BLOCK,
respectively.
b) Sectorama commands
==================
All the sectorama commands are adequately described in the documentation
file that accompanies it.
c) A Practical Session
===================
i) Touring a floppy, a summary
---------------------------
I suggest that as you progress through this little step-by-step
blathering that each time you come across a new type of block, you
compare the data being displayed by sectorama to the block
descriptions shown above so that you become more familiar about where
things are located in each type of block.
The steps for performing the operations summarized below with
Sectorama are described in detail, with a running commentary, in
section ii) Touring a floppy with Sectorama. For following these
steps with any other disk editor, I suggest that you quickly read
through the Sectorama tour to familiarize yourself with what is
being attempted, then attempt the summarized steps below to familiarize
yourself with your disk editor and AmigaDOS.
Steps 1 thru 8 will guide you from a disk's ROOT BLOCK, into a file
and through all the data blocks in that file. A quick summary of
these steps is as follows:
Steps 9 thru 14 show you how to alter a block and write it to disk.
_A step-by-step of the tour, in summary is as follows:
/ 1. Run the disk editor.
|
| 1a. (Load the root block. This is done automatically by Sectorama.)
|
| 2. Locate the 'c' directory by using the hash function.
Part< 3. Load the USER DIRECTORY BLOCK for the c directory.
1a | 4. Locate the 'dir' command file by using the hash function.
| 5. Load the FILE HEADER BLOCK for the 'dir' file.
| 6. Load the first DATA BLOCK of the 'dir' file.
| 7. Load and examine each consecutive DATA BLOCK of the 'dir' file until
| the last DATA BLOCK in the file has been loaded and examined.
\_8. Load the FILE HEADER BLOCK pointed-to by the final DATA BLOCK.
_
/ 9. Locate and select the first word in the comment filed of the FILE
| HEADER BLOCK for the 'dir' file.
| 10. Edit the ASCII values of the comment field.
Part< 11. Edit the hexadecimal value of the first byte of the first word of
1b | the comment field to insert the string length of the comment
| created in step 10.
| 12. Re-calculate the checksum for this block.
| 13. Write the altered block to disk.
\_14. Quit the disk editor.
ii) Touring a floppy with Sectorama...
----------------------------------
1. O.K., get your disk editor up and running (if it isn't already)
and begin examining a back-up copy of your workbench disk. For
sectorama, the CLI command line for this if the disk was in df0:
would look like:
1> run sec df0:
What you will see on your display (in neato-keen hi-res) is data
of the ROOT BLOCK of df0:. On top of the display is 'Type=ROOT DIR'
which indicates that the block currently being displayed is a
ROOT BLOCK.
2. Now that we are at the ROOT BLOCK, lets find the c directory. The
first step for this is to find out what value we get when we use the
hash function on the string 'c'. To do this you must envoke the hash
function by picking 'COMPUTE HASH VALUE' under the SEARCH menu, then
typing the file or directory name, in this case the letter c followed
by a <RETURN>. This highlights the block address of the hash chain
which contains the c directory.
3. Now that you've found the possible whereabouts of the c directory
jump to it by hitting the j key. If (more likely than not) on top of
the display is 'Name=c' then the display is currently displaying the
contents of the c directory and the top of the display has
'Type=DIRECTORY' indicating that what is being displayed is a USER
DIRECTORY BLOCK, which is essentially the c directory of df0:.
4. Now that we're at the c directory, let's look at a file containing
loadable/executable code for a well-known function... say, the file
called 'dir'. Envoke the hash function as before using the string
dir. The block address of the hash chain that contains the dir file
will be highlighted.
5. Press the j key to jump to the beginning of the hash chain which
will have (again, more likely than not) 'Type=FILE Name=dir'
displayed above the table of block data. The Type=FILE indicates that
this is the header block for the file indicated by Name=dir. This is a
fairly short file, so that all the block addresses for the DATA BLOCKS
for this file are included in this block and that no extension blocks
are required for this file, which is why the block address beside
'X-Go Extension=' is 00000000.
Also notice that the block address beside 'D-Go Next Data' is the
same as the last entry in the data table of this block (at word # 4D
according to my version of dir). This is because data blocks are
arranged in this table starting at the end of the table and working
towards the beginning.
6. Let's take a look at the first DATA BLOCK, then, by hitting the
d key to 'Go Next Data'. What will be displayed is the first DATA
BLOCK of the dir file. On top of the display will be 'Type=DATA BLOCK'
confirming that fact. Note that word # 04, which has the same value as
is displayed beside D-Go Next Data =, points to the next DATA BLOCK for
this file.
7. Let's traverse the entire list of DATA BLOCKS to see what the last
one in the list looks like. You can do this by hitting the D key
about 16 times or so. While you do this, note that the value beside
H-Go Header = stays constant for each data block while all the other
values remain constant. The value beside H-Go Header = points to
the FILE HEADER BLOCK which owns the DATA BLOCK. If this ever changes
as you are traversing a list of DATA BLOCKS, you KNOW there is a
problem with the file. Also note that as you jump from block to block,
the HISTORY list at the bottom of the display keeps track of your last
eight jumps. This is a valuable feature when you overshoot a problem
area and need to know where you've been in previous jumps. Also note
that for each successive DATA BLOCK that you display, the sequence
number displayed in the middle of the right part of the screen is
incremented by one. This helps you figure out exactly where you are in
the file you are looking through. If ever this sequence number jumps
up or down by more that one, you know the DATA BLOCK is out of its
proper sequence.
8. Once you've reach the end of the DATA BLOCK list, you will find that
hitting the D key will now only cause the display to flash, indicating
that this is indeed the end of the DATA BLOCK list for this file. Lets
jump back to the FILE HEADER BLOCK for the 'dir' file by hitting the
h key (for H-Go Header).
9. Now that we've jumped around the disk doing some block reading,
let's get more adventurous. Let's modify a block on the disk. By
comparing the FILE HEADER BLOCK description above, we note that the
comment field in this block begins at word # 52 and ends at word # 68.
Move your pointer to word # 52 and click your left mouse button to
highlight it.
10. Next, press the A key to enter ASCII edit mode (the command list on
the right of the display describes it as Edir ASCII). Now type a space
and then some sort of short comment, being careful not to type past
word #68. For example, I typed the comment ' dir, oh dir' beginning
in word #52. Note that the delete key and backspace key do not work
normally in this mode, and actually produce their own special ascii
values. To re-type something, you must either move your pointer to the
desired location and click, or use your cursor keys to move the
highlighter to the desired character, then type your correction.
To exit this edit mode, simply hit <RETURN>.
11. To make our comment a proper BCPL string, we must put a character
count at word # 52. Count how many characters there are in your string
and convert this number to hexadecimal. Next, enter the hexadecimal
edit mode by hitting the e key (for Edit), type your two-digit
hexadecimal value and hit return. For example, in my 'dir, oh dir'
comment there are eleven characters. Eleven converts to 0B in
hexadecimal, so I edit word #52, type 0B, and hit return.
12. Since we've altered the contents of this block, the checksum for
this block is no longer valid. We must hit the k key to calculate a
new checksum. When you have done this, you will note that the value
beside K-Checksum = and at word # 05 have changed to the newly
calculated checksum.
13. Note that any changes you have made so far haven't been written to
disk at all. Nothing is ever written to disk until you actually write
it by hitting the u key to 'Update block'. To incorporate your new
file comment for the file called 'dir', hit the u key.
14. Then quit Sectorama, and list df0:c/dir to see the
change that you've just made. Note that you may have to list the whole
c directory to see the change since AmigaDOS keeps track of which
sectors of which device it currently has in buffers, and will avoid
fetching your modified sector if it is currently in df0:'s buffer.
What we've just done is to examine a disk, seek-out a specific file,
look through the file's data, then modify the FILE HEADER BLOCK of
that file. What we haven't seen yet are two important data
structures which we will look for now. Specifically, these structures
are the hash chain, and the file list.
1. to 3. Same as steps 1. to 3. above. (Locate & load the c directory)
4. Now calculate the hash value for Echo using the Calculate Hash Value
function. Write the highlighted number down.
5. Calculate the hash value for Quit using the same hash function used
in step 4.
6. Calculate the hash value for Why using the hash function. You will
find that the value you have written down for the value calculated for
Why, Quit, and Echo are all identical, implying that if you jump to
this number, you will have access to all three files.
What this really means is that the FILE HEADER BLOCKS of these three
files are members of the same hash chain.
7. Jump to the first file in the hash chain by hitting the j key. I
cannot say exactly which FILE HEADER BLOCK you will be shown, since
that depends on in what order the files in the chain were created on
this disk. Note that the value beside P-Go Parent = is that of the
USER DIRECTORY BLOCK of the directory containing this file, namely the
c directory.
8. Note that the block address beside C-Go Hash Chain = is non-zero.
At least, if the files Echo, Quit, and Why are in the c directory on
this disk, the value will be non-zero. Otherwise, this demonstration
will not be successful. To display the header of the next file or
directory in this hash chain, hit the c key (indicated by C-Go Hash
Chain).
9. Note that the value beside P-Go Parent hasn't changed. This is
because all members of a hash chain always belong to the same
directory. To traverse the hash chain and find the last FILE HEADER
BLOCK or USER DIRECTORY BLOCK in the chain, keep hitting the c key
until the value beside C-Go Hash Chain becomes zero. When this
happens, further presses of the c key will merely cause the display
to flash, indicating you are at the end of the hash chain.
10. Jump back to the ROOT BLOCK by hitting the r key.
To find what an extension file looks like, we must look for a large
file... one where the amount of data is large enough that more pointers
are available in a FILE HEADER BLOCK's DATA BLOCK pointer table. A
DATA BLOCK pointer table usually has 72 available entries. Since each
BLOCK is 512 bytes long, we need a file that is over 72 x 512 = 36864
bytes long. The Preferences file is about twice that length, so let's
take a look at it.
11. Calculate the hash value for Preferences using the hash function.
12. Jump to the FILE HEADER BLOCK for the Preferences file by hitting
the j key. You will note that all the entries in the DATA BLOCK
pointer table in this FILE HEADER BLOCK are used-up. You will find
the rest of the pointers required to point to the rest of the DATA
BLOCKS for this file in the file list. The block number of the first
FILE LIST BLOCK in the file list is shown beside X-Go Extension.
13. Hit the x key to jump to the first FILE LIST BLOCK. Note that the
block number displayed beside P-Go Parent is the same as the block
number of the FILE HEADER BLOCK to which this FILE LIST BLOCK belongs.
Also note that the value beside X-Go Extension is now zero. If the
required even more DATA BLOCKS, that is, if the file was longer than
about 73kbytes, the value beside X-Go Extension would point to the next
FILE LIST BLOCK in the file list.
So, that pretty well wraps-up the tour. We've seen all the data
structures used by AmigaDOS and have had a chance to modify a block.
There are a number of implications of AmigaDOS structure that this
document hasn't covered, but these things will become apparent as you
are given the opportunity to apply the disk editor.
I hope the information forwarded by this document will help you solve
or at least understand problems that may occur from time to time when
storing things on AmigaDOS compatible devices.
A Trouble-shooting Example
--------------------------
This information was recently invaluable to me as I discovered a
problem with my hard drive recently that could have blossomed into a
fairly major disaster. A file was written on top of another file.
I kept getting a read/write error when I tried to copy the
over-written file to another device. So, I examined the hard drive
with Sectorama. I used the hash function to locate which hash chain
the file was stored under, traversed the hash chain until I found the
file header block of the file in question. I then traversed the list
of data blocks for the file by hitting the d key repeatedly. The
list seemed to be intact since I was able to follow the list to its
last block.
I then hit the h key to display the file header block again. It
was the file header block of an entirely different file! So, I jump
back to the root, jumped to the file I was originally investigating,
and again traversed the data block list while watching the value
beside H-Go Header for any changes. About half-way through the file
the value changed. I noted the block number of that data block,
hit the h key to jump to the wrong file header block again, and noted
that the block number of the erroneous data block was listed. I went
back to the root block and back to the original file header block and
found that the same erroneous data block was listed here, too.
I checked all the files on the hard disk, and found that only one
file was unreadable. Thus, that file had been overwritten. This
implied that somehow the bitmap of the disk was erroneous since the
data block used by the file was claimed by another file. I had to
backup-up new files, format the hard drive to prevent further calamity,
and copy back all the files. That cured the whole problem.
I had a directory problem a while ago that I now know how to fix
recover from with a disk editor. The directory of a device wrapped
around so that when I executed a list command, I got an endless
repetition of the same files, while other files on the disk would
never be listed. When I listed the ignored files by naming them
directly, they would show up. If I executed a dir command, the
storage device was searched and searched and searched until the
computer crashed. I believe that is due to dir's method of collecting
all files in a directory for sorting until the end of the directory
is reached, which, in this case, it never did.
Solving this is a matter of copying all files possible to another
device. This means individually copying all the files since wildcards
cause a directory search which, in this case, would never end. The
files you cannot see can be searched-out with Sectorama using wildcards
since Sectorama provides full-disk searches without consulting a
directory. After finding and copying all your files to another device,
I'd recommend formatting the device to remove anything that might cause
a relapse of the problem.
If you have any corrections, comments, or suggestions about the above
document, please send them to me or tell me about them. You can reach me at:
//
\X/ Tesseract BBS
(306)757-5699
(24 hours, 8N1, 300 or 1200 baud)
address: Dwayne Miller
770 Robinson Street
Regina, Saskatchewan, Canada (Yup, way up there!)
S4T 2M1
voice: (306)525-1652
P.S. Sectorama was written by David Joiner of MicroIllusions and is commonly
available, often named 'sec.arc' or 'sector.arc' or 'sectoram.arc' etc.
