Mac Geekery

Ever get that lovely “overlapped extent allocation” or “missing extent” error when checking your drive in Disk Utility? Notice how it never gets repaired when you repair the disk? There’s a reason: it’s technically irreparable.

The extents that the error is referring to are the file fragments on your drive. There’s a special catalog file called the extents B-tree (this is also sometimes referred to as the extents or extents overflow file) that holds all of the information on which files have which fragments on the disk. Each fragment is an extent. When you have a missing extent then you have a record that states that there are a certain number of extents for a file, but the known extents are too few for that file. When you have overlapping extents then you have two extent entries that share a series of blocks. In either case, the file is probably dead. Either a part was lost or a part was overwritten by another file. While Disk Utility reports this as a catalog error, it’s merely an accounting error, though one important enough to have caused a file to go buh-bye.

In each error, however, there’s a number. That number is the file ID number (aka inode) and will help us locate the file that’s causing the problem. Knowing which file is busted gives us an idea on what it will take to fix it. If it’s one of your data files, restore from the backup you should have. If it’s a system file, we can look at the BOM for the last combination update and see if we can get it back that way.

In either case, you’ll see one of the following lines, depending on the error and your version of Mac OS X:

Before 10.4.2

** Overlapped extent allocation (file 9053642d)

After 10.4.2

** Overlapped extent allocation (file 8747098 /User/luser/Documents/BackupStrategy.doc)

Mac OS X 10.4.2 changed a lot of things with how Disk Utility handles extent overlap problems. While some may think that the updates actually let it repair the problem, what it really does is expose it so that you can fix it.

So, Fix It.

Take the number from above (before 10.4.2, ignore the ‘d’ at the end) and enter it into a find command:

find / -inum ####

You may choose to run this under sudo so that it can see into all the directories on the system and have a better shot at finding the file. When it does find the file with that inode it will print out the location. Go ahead and cancel the search (control-C or command-period in Terminal) and inspect the listed file, if possible. If the file is one of yours, either restore it from backup or take some time to ponder how you’ll backup from now on to prevent the inevitable feelings of depression that now waft over you.

If the file is a system file then we need to find out if it’s something that’s been added in an update you can download or if it’s a core file that hasn’t been updated since your installation of the OS. To do this, let’s presume the file that broke was:

/System/Library/CoreServices/Front Row.app/Contents/PlugIns/DVD.frappliance/Contents/Info.plist

How, then do we know if we can just download that file or not? Simple: check the Bill of Materials files that the Installer leaves behind. Run the following:

find /Library/Receipts/ -name '*.bom' -print0 | xargs -0 -IFILE /bin/sh -c "lsbom -s 'FILE' | grep -q DVD.frapp && echo FILE"

Rather than searching for the full path, I found a unique series of characters in the path to the file and searched on that. You could search on the whole path if you like, but this is all you really need. What the line above does is:

1. Finds and returns the paths to all the BOM files the Installer has created.
2. Spawns a new shell with a chained command that…
3. Lists the contents of the BOM file
4. Sends it to grep to search for the string we’re interested in and
5. If a match is found, print the name of the file we just searched.

In this case, I received the following results:

/Library/Receipts//boms/com.apple.pkg.Essentials.bom
/Library/Receipts//FrontRowUpdate2.1.3.pkg/Contents/Archive.bom
/Library/Receipts//FrontRowUpdate2.1.3.pkg/Contents/Resources/FrontRowUpdate2.1.3.bom

What this means is that the file was installed with the OS (Essentials) and then updated with the last Front Row Update. Reinstalling Front Row Update 2.1.3 should resolve my issue and replace the damaged file, then.

Ta da.

References

Handling ‘overlapped extent allocation’ errors reported by Disk Utility or fsck

Inside Mac OS X 10.4.2

Select ratingCancel ratingPoorOkayGoodGreatAwesome