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...
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.)
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.
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.
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.