On Monday, March 25, 2002, at 11:37 PM, Entwicklung wrote:
I think there must be some problem with the referencing (data fork locations in the leaf nodes) so I checked this but it seems to be fine (just like it is for the first 3 index nodes which work perfectly) . Since all the icons get displayed correctly I thought the problem must lie within the leaf nodes but this doesn't seem to be the case. On my Mac I get an error of the form "Schreib/Lese Fehler" or "Read/Write error"..... What could this be due to ? Checking with hfsutils under Linux gives me the error "Wrong logical location" or similar.... does anybody know what this is due to?
Two quick guesses: you have keys out of order, or one of the node numbers ("pointers") in an index node is wrong.
When Mac OS iterates over the contents of a directory, it generally starts by searching for the thread record of the parent directory (the key is the directory ID and empty string), and then iterating to the next leaf record. It continues iterating to the next leaf record until it finds a record where the parent ID is different. The code maintains some state about the current position of the iteration (i.e. node number and record index within the node). The "next leaf record" operation just increments the record index until that is larger than the number of records in the node; then it follow's the leaf node's "next" pointer. This kind of iteration tends to ignore the index nodes, so corruption in the index nodes isn't detected yet.
Then when you try to do something with one of those objects (eg., open a file), the object is specified by parent ID and name. That means the File Manager has to search through the B-Tree for that specific object. That requires comparing keys and following pointers in the index nodes.
If the keys are out of order, or index nodes are pointing to the wrong nodes, you are more likely to get some kind of "not found" error. The "Read/Write error" and "Wrong logical location" suggest that some number (such as a node number in an index node) is out of range. Another possibility is that the extent information or end-of-file for the B-tree is wrong (probably too few allocation blocks), so the node numbers refer to offsets beyond what the File Manager things is the end of the B-tree.
-Mark