Hi,
The internal format of HFS disks is described in considerable detail in
Apple's "Inside Macintosh: Files", published by Addison-Wesley. A
must-read if you plan to modify a catalog B*-Tree by hand...
>Corresponding to the '..' directory entry, each group of files
>belonging to the same directory is preceded by a special type of entry
>called a thread entry. It's key is just the ID number of the
>directory, with an empty filename appended. It holds the ID of the
>directory's parent.
Actually, it holds the complete key by which the directory is known: the
parent's dirID and the name within the parent's directory. It allows the
filesystem to locate the catalog record describing the directory itself
(its mod. date, etc.)
>What appears likely is that one of more "pointers" in the tree have
>become corrupted and so the thread records for the "missing"
>directories are inaccessible. This surely means that the entries for
>at least some of the entries in those directories are also
>inaccessible, but not necessarily ALL of them. It may still be
>possible to access some files or directories in the "missing" ones by
>name, but not by 'ls', 'find', 'du' or anything else which tries to do
>the equivalent of an 'ls' in the "missing" directories. If you know
>the names of files under the "missing" directories, then give it a
>try.
The damage can be on two levels: in the B*-Tree itself (an index node
pointing to two subnodes that aren't linked along their forward and
backward links, for instance) or in the structure of the B*-Tree records
(missing thread records for directories, for instance).
Without knowing more I wouldn't speculate on the kind of damage your disk
may have sustained. Machine crashes do different damage than hard disk
bad blocks, for instance.
Locating an object by DirID and Name involves doing a traversal of
successive levels of index nodes in the B*-Tree in order to locate the
leaf node that holds the actual record for the object in question.
Opening a folder involves locating the thread record of that directory
(because it always immediately precedes the record for the first object
in the directory), followed by a traversal of successive forward links to
enumerate the contents of the directory. It is possible to end up in a
situation as described above although the reverse is more common: the
leaf links are intact allowing a directory to be enumerated but, even
though the contents are plainly visible in the Finder window, trying to
do anything to any of them results in a "File Not Found" because the
index node superstructure is corrupted and the file cannot be found by
its ID/Name key.
>In principle the "extents tree", which holds to info on what blocks
>are used by what files, should still know about the files with
>inaccessible catalog entries. If an fsck existed, it would do as
>Michael Knox suggests: find all catalog entries is COULD get to and
>then find al the extents that weren't accounted for by the accesible
>catalog entries and make them into files again, thought there names,
>types, and otehr vital statistics would be lost. This is what Norton
>tries to do too, but I imagine that the catalog tree is too badly
>damaged for it to be able to create any entries for the lost files. I
>think you should assume that is the case any not try to create of
>delete any files or directories on the disk for fear of further
>corrupting the catalog tree.
Unfortunately (from a recovery standpoint) not all extent information is
in the extents B*-Tree. In fact, it's somewhat rare; the first 3 extents
of any file are stored in the catalog record for the file itself. It's
only when a file allocates a fourth extent that extent records are
created in the extents B*-Tree (which is really an extents OVERFLOW
tree). If it helps any, the resource header (in the first block of a
resource fork) contains the file's name and some of the Finder info. You
can tell resource fork extents because there's a flag byte in the extents
B*-Tree key that's different for data fork blocks and resource fork
blocks.
>My only USEFULL suggestion is to be sure you have the newest Norton
>Utilities for Mac which you can find. There is always the hope that a
>newer version can fix the problem.
That's certainly sound advice. Looking over the remains of a corrupted
hard disk can be educational and fun but the repairs are not for the
faint of heart. I wouldn't dive in without reading some source for
information on the volume format, and the "Inside Macintosh" volume does
a remarkably thorough job.
Hope that helps,
-Pat Dirks.
