Hello listers, I've encountered a problem which I am not able to attribute to anything particular and would like to know if I am making any basic mistake or have overlooked something.
I'm creating a catalog B-Tree with 1 root node (index) containing five ptr recs to a second level of five index nodes, each of which contains 11 pointer records to 11 leaf nodes each. The problem I'm facing is that the files referenced by the last 22 ptr recs i.e. in the last 2 lower level index nodes are not readable on my Mac although the correct Icons do appear and all my files are displayed.
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?
I think it must be some basic mistake I am making (related to the HFS-Specifications perhaps ?) but I have been unable to narrow it down so far..(hlp!).. would be glad of some professional advice.
Regards, Nandini Hengen
At a guess I'd say check all the FID and DIDs are valid and unique
On Tue, 26 Mar 2002, Entwicklung wrote:
Hello listers, I've encountered a problem which I am not able to attribute to anything particular and would like to know if I am making any basic mistake or have overlooked something.
I'm creating a catalog B-Tree with 1 root node (index) containing five ptr recs to a second level of five index nodes, each of which contains 11 pointer records to 11 leaf nodes each. The problem I'm facing is that the files referenced by the last 22 ptr recs i.e. in the last 2 lower level index nodes are not readable on my Mac although the correct Icons do appear and all my files are displayed.
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?
I think it must be some basic mistake I am making (related to the HFS-Specifications perhaps ?) but I have been unable to narrow it down so far..(hlp!).. would be glad of some professional advice.
Regards, Nandini Hengen
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
Hi,
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.
I finally found out what the error was due to. Thanks for the explanation regarding the sequence of events - I didn't know that Mac iterates thru' the leaf nodes at the start. The problem was with the index nodes present in the final sectors which had got currupted while recording onto a disk. Since the Mac didn't complain about the absence of an alternate MDB and I used a local image for verification I didn't quite understand what was happening.... now that the final sectors have been 'set right' the index nodes are also read correctly and all the files can be opened.
I've been following up threads on other lists as well. I would just like to convey to the list that I think that Apple is doing a great job out here. Everyone has rules which have to be stuck to though rules can never be in the interests of everybody and may not be always fair in everyone's eyes. I just want to mention that the Apple employees don't have to reply to every email they get but the fact that some of them do find the time to do so has to be appreciated. I'd probably be totally lost but for the tips I get from them once in a while. Thanks !
Regards, Nandini Hengen
-
Entwicklung -
Mark Day -
Simon Bazley <sibaz＠sibaz.com>