For anyone else who may care now or in the future, I've continued to experiment with this and I've concluded that the Extent Overflow File itself cannot have more than the three extents that are stored in the MDB. This means it will never contain any records referring to itself and so any process reading the structure doesn't need to look for additional later extents beyond what it can find in the MDB. Likewise, code trying to update the file should never try to create a fourth extent or create any records in the extent file that refer back to it.

First, as I alluded to earlier, upon initialization of the volume, the first extent created for the file is large enough that it's unlikely to ever fill up completely under typical usage patterns. If the second or third extent does need to get created the system tries to create it as the same size as the first (there would need to be an open space at least that large on the disk). It appears that if the three extents stored in the MDB are all full-sized then that's just enough space to store enough records for the case where each allocation block on the disk is an individual extent. An extreme worst case scenario that's impractical to ever approach.

Where you might run into something under more unusual amounts of fragmentation would be where there aren't any gaps large enough to create the second or third extents at full size. In that case you could potentially fill up the file to the point where a fourth extent might be needed but this would be difficult to reach through typical means either intentionally or unintentionally. You'd probably have to incrementally lengthen a number of files many times so that they became all intertwined. That's not something that could be easily done or that I even attempted.

Instead, I tried to create this state artificially by manipulating the data structures on the disk. One thing I tried was to modify the size of the extent file so that each extent was smaller and it was much easier to fill up. I also tried a different approach where I left the file itself alone but marked a tight pattern of used blocks in the volume bitmap so when I copied a file in it quickly became highly fragmented. Then I just removed the flags I set and was able to copy in more files which also became highly fragmented. This also had the effect of forcing the second and third extents for the overflow file to be much smaller due to lack of a large opening on the disk.

I tried each approach a number of times and the result was always the same. The system never created a fourth extent which I could tell by comparing the size in the drXTFlSize field to the number of blocks in the drXTExtRec field in the MDB. Whenever I tried to save a file that would have required creating the fourth extent the operation failed and I got a popup with the crypt error message "Unknown Error." If the second or third extents didn't already exist then they were created after that but otherwise there were no logical changes to the file system. I take that to mean that lower-level code errored out when it realized there wasn't enough overflow space to store all the required extents. Since this should basically never happen it's not surprising it's not handled more gracefully.

In conclusion, I think the system is designed such that enough space is preallocated in the overflow file so that it basically never needs to grow larger than what can be referenced directly by the MDB. This avoids the complexities that would arise with reading and writing the file when it contained entries to it's own later extents. I did all this testing in Mini vMac II running System 7.5.5 and mostly with an image the size of a high density floppy disk.

If I write any utilities in the future I plan to validate the image by checking that the drXTFlSize and drXTExtRec fields agree on the length of overflow file. I think the System Software might also make this same check and reject the disk as uninitialized if they don't match.

I still wonder about why the CNID is assigned for the overflow file in Inside Macintosh though.