Hello,
I'm still working on my HFS/HFS+ image formatter and I get a problem.
I build a HFS image with about 41000 little files.
The catalog mapping bitmap in the B-tree header overflows at about 6,500 files. The first independent node overflows at about 18,300 and the second at about 30,400 files.
Therefore, I have following linkage: 0 (header) points to 0x0800 0x0800 points to 0x1770 0x1770 points to 0x26E0
However, when I run fsck_hfs on the CD-ROM I burned from this image, I get an error message:
Invalid map node linkage 4, 9952
Btw, 9952 is 0x26E0 in decimal, which means that the program is not happy with my solution, in particular with the last node in the linked list.
When looking at several volumes formatted and filled on a Macintosh (Mac OS X 1O.2, if it matters), I see that there is always a totally empty node (with nothing in it, even in the node header) pointed to by the last node where the bitmap was used.
Should I also implement this?
Thanks in advance for any clue.
On Jun 11, 2004, at 8:33 AM, Pierre Duhem wrote:
Hello,
I'm still working on my HFS/HFS+ image formatter and I get a problem.
I build a HFS image with about 41000 little files.
The catalog mapping bitmap in the B-tree header overflows at about 6,500 files. The first independent node overflows at about 18,300 and the second at about 30,400 files.
Therefore, I have following linkage: 0 (header) points to 0x0800 0x0800 points to 0x1770 0x1770 points to 0x26E0
Is node 0x26E0 an actual header node? The chain of forward links in the header node list should end with a forward pointer of zero in the last node.
However, when I run fsck_hfs on the CD-ROM I burned from this image, I get an error message:
Invalid map node linkage 4, 9952
Btw, 9952 is 0x26E0 in decimal, which means that the program is not happy with my solution, in particular with the last node in the linked list.
When looking at several volumes formatted and filled on a Macintosh (Mac OS X 1O.2, if it matters), I see that there is always a totally empty node (with nothing in it, even in the node header) pointed to by the last node where the bitmap was used.
Should I also implement this?
No - that sounds like a bug. No node in the tree should ever be without a node header. Just link the valid nodes together with a zero link in the last node.
If you can reproduce the generation of a volume with an empty node linked in, please let us know. That sounds like a bug.
Thanks, -Patrick.
Thanks in advance for any clue.
-- Best Regards Pierre Duhem Logiciels & Services Duhem, Paris (France) duhem@macdisk.com
On Jun 11, 2004, at 8:33 AM, Pierre Duhem wrote:
I build a HFS image with about 41000 little files.
The catalog mapping bitmap in the B-tree header overflows at about 6,500 files. The first independent node overflows at about 18,300 and the second at about 30,400 files.
Therefore, I have following linkage: 0 (header) points to 0x0800 0x0800 points to 0x1770 0x1770 points to 0x26E0
However, when I run fsck_hfs on the CD-ROM I burned from this image, I get an error message:
Invalid map node linkage 4, 9952
That error is E_MapLk in the code. What it's doing is following the chain of forward pointers starting with the header node (i.e. following the chain of nodes containing map records). It is adding up the sizes of each of the map records, in bytes, in order to compare with the number of bytes needed to map all of the nodes (based on the total node count in the B-tree header; don't forget to round *up* to whole bytes!). The error is reported when one of the following happens:
1. A forward link of 0 is found, but the sizes of the map records aren't large enough to map all of the nodes. That is, it was expecting to find additional map records.
2. A non-zero forward link is found, but the map records found so far have enough space to represent the total number of nodes. Note that it is OK for the very last map record to be larger than strictly necessary (based on the total number of nodes).
Either case could happen if the total node count is wrong, or if the record offsets in the header node or map nodes are wrong.
Btw, 9952 is 0x26E0 in decimal, which means that the program is not happy with my solution, in particular with the last node in the linked list.
My first guess is that you didn't set the forward pointer in node 0x26e0 to zero.
When looking at several volumes formatted and filled on a Macintosh (Mac OS X 1O.2, if it matters), I see that there is always a totally empty node (with nothing in it, even in the node header) pointed to by the last node where the bitmap was used.
Should I also implement this?
That shouldn't be happening. Any node pointed to by any other node in the tree should have a valid header. And any node not in the tree should be filled with zeroes.
-Mark
-
Mark Day -
Patrick Dirks -
Pierre Duhem