Lost Files
Volume Number: 1
Issue Number: 8
Column Tag: Forth Forum
"Recovering Lost Files
By Jörg Langowski, Chemical Engineer, Fed. Rep. of Germany, MacTutor
Editorial Board
Recovering lost Files - File Tags
Before we start the main topic of this month's column, let me make an addition to
my article in the May issue (Vol1 #5). I have so far made no distinction between using
MacForth 1.1 and 2.0 for any of the program examples given here. And it is true, the
main difference between the two Forth versions that appears on the surface is that
Forth 2.0 contains the word ADD.CONTROL, which you have to define for yourself in
Forth 1.1 (see V1 #4).
One thing, however, does change between the two versions. The tokens of
predefined words are not the same anymore. Therefore, the example that I gave in the
May article (for which I happened to use Forth 2.0) does not work with Forth 1.1. In
1.1, the tokens for the two 'no-name' words are:
2C1A instead of 2C7C for the 'wrapping tab' function, and
2BF6 instead of 2C58 for the wraparound function.
This month's example will make use of the latter function, so watch which Forth
version you are using when you try it out.
Forth on the Mac can be compared to a set of very powerful, very sharp tools. You
can create beautiful things with it; you can also cut yourself pretty badly. Cutting
yourself with Forth can show up in a variety of disguises: the Bomb (and you may even
be able to Resume!), interesting geometric patterns on the screen, requiring you to
push Reset, strange machine gun type noises from the speaker, or all of the above. Of
course, the MacForth editor automatically backs up screens and protects you from
many disasters, but I left out something from the list a disk drive running wild,
erasing some of your last half day's hard work or even the directory.
The people who designed the Mac have provided a very clever 'safety net' for those
types of crashes. The operating system not only maintains a directory of the disk which
associates to each file the blocks it is written to, it keeps additional information with
each physical block: which file it belongs to, what its position in this file is, what the
attributes of that file are and when it was written. Therefore, in principle, you can
reconstruct any file on the disk, even without the directory being intact, just by
reading all the blocks on the disk and looking where they belong.
The information that is kept with the blocks is not much; otherwise too much disk
space is lost. So you won't be able to keep track of file names this way, nor of file types
or creators.
An update to Inside Macintosh
The extra bytes that go with each sector are called tags. Inside Macintosh
documents that there are 12 tag bytes per block and that they contain the following
data:
bytes 03 : file number (long word)
byte 4 : file attributes (byte)
byte 5 : seems to be unused
bytes 67 : sequence number of this block within the file
bytes 811 : date block was written
This table deviates a little from the one that was given in the File Manager section
of Inside Macintosh (at least in the most current update that was available to me in late
April, when I wrote this). Inside Macintosh puts the attributes byte at position 5 in
the tags block, and says that bit 0 of byte 4 is set =1 when the file is locked, =0
otherwise. My experiments, using the example program (see below), could not
confirm this. Byte 4 contains all the file attributes, including whether the fork is
resource or data (bit 1 =1 or =0, resp.).
The File Tags information is not written to the file buffer that you pass to the OS
routines in the file control block. Rather, after each read operation, the tags are
stripped from the main part of the block and placed into a special position in memory,
which is referred to by the system global TagData (=$2FA). You will find the 12 tag
bytes starting at TagData+2; I was not able to figure out what is contained in TagData
and TagData+1. Inside Macintosh claims that the last 4 tag bytes (the block
modification date) are not put into memory here, but that the logical block number
appears at TagData+10 to TagData+11. This could not be reconfirmed, either; any time
you read a block from disk, you will find the modification date of that block at TagData
+10.
Reading and writing tags
In which way do the tags influence file handling by the operating system? Not at
all, as long as the directory is intact. You can not only read tags, but also by changing
the memory block that contains them and writing the 512 byte buffer back to disk,
modify the tags (and even give them nonsense values). This, as far as I was able to find
out, does not change the behavior of the disk in any way. If you write a block on a disk
back in place, with only its tags modified (saying e.g. that it belongs to a different or
non-existent file), the file containing that block will still be useable.
I tried this on a copy of a MacWrite disk, changing a couple of block tags in the
MacWrite as well as in the System and Finder files. The disk would still boot nicely
afterwards, and also after booting with Option-Command pressed (thus reconstructing
the Desktop file), nothing peculiar was seen. Therefore it seems that the block tags are
really nothing but an additional safety measure to help you (or some utility routine)
reconstruct a crashed disk.
This is basically what Inside Macintosh says, too. And it is also said that there
would be a utility (to come) that will automatically repair a destroyed disk from the
tag information. Alas, no such thing has ever crossed this editor's desk and it still
seems to be one of the numerous vaporware items for the Mac. (If any of you who read
this column know better, please correct me and also tell me where to get such a
routine). So far, the little Forth program at the end will have to do.
Recovering lost files
This month's example program is an update of the disk editor published in V1#5.
Since I made a couple of changes to different parts of the program, it is printed in full
length again. For one thing, the block length was changed from 1024 to 512 bytes,
since tags refer to logical blocks, not allocation blocks. The new features that have been
added are words to extract tag information from the system globals area and print it
formatted; furthermore, you can dump the whole disk block by block, showing the tags