This article is now online at macfixit:

Overlapped Extent allocation errors in Mac OS X 10.2.x: LimeWire can cause, how to fix







The peer-to-peer file sharing tool LimeWire - updated to version 3.3.4 yesterday - is apparently one cause of "overlapped extent allocation" errors (meaning that you have two files referencing the same "extend") on some Mac OS X systems.




Unfortunately, the traditional UNIX command fsck (accessible in GUI mode via Apple's Disk Utility) is unable to repair this problem, and your system can experience performance degradation as a result.




One MacFixIt reader writes: "I had two files (discovered by fsck) that had extent allocation overlaps. When I deleted some recently-imported LimeWire downloads, the problem (the extent allocation, not the kernel panics) disappeared."
Since Unix directories are simply pairs of filenames and inode numbers, you can use the following Terminal command to locate files that have overlapped extent allocations - all of them contain the inode xxxx - and delete those that exhibit the problem:

find / -inum xxxx







However, do not delete files at random. You could be erasing critical system components. Only delete files that you are sure you have recently downloaded and are not necessary to the System.




Some readers have also had success with Disk Warrior 3.0, which re-builds directory data on a disk (Apple's Disk Utility does not repair directory damage.)




If worse comes to worst, you are left with few other options than to simply perform a fresh install of Mac OS X on a formatted disk. Do not attempt an "Archive and Install" procedure. Doing so when there are unresolved directory issues can make the issue worse, and possibly lead to data loss.

Odd. We leave all native filehandling up to Apple's Java implementation, so it's strange that LimeWire specifically would be causing problems. Perhaps it's just that LimeWire is a very prevalent java application for macs, and is uncovering bugs in the implementation.

We'll look into it though -- thanks for the report.

If this is true than this points to a severe problem in Apple's file system kernel code. A user level process (without any kernel extensions) should never be able to corrupt the file system data structures, be it Java code or a C programm.

Very interesting, but way over my head. This reply seems to reinforce what both of you said:

"I have never had either of these problems despite all my crashes (lots)
and kernel panics (two). It should also be impossible for LimeWire to
cause these errors - either way, it's a bug in the file system drivers.

OSX has other oddities, like writing to the console taking up space even
though console.log is taking up none ('echo > /var/tmp/console.log'
usually doesn't keep it at zero size). There was also the 10.1 thing where
swapfiles took up no space (as reported by df).

Most of the time, though, all fsck reports is 'orphaned extent allocations'
or something (allocated space on disk that doesn't belong to any files). "


Anyway, the thread is viewable at macfixit.com. In case you want to reply and/or defend directly so that macfixit does not post incorrect information.

Dear Limewire folks.
My machine's directory appears to have been damaged after downloading, installing and using Limewire 3.3.4.
Disc Warrior moved the overlapped files to new locations and seems to have repaired my hard drive. I am running Mac OS 10.2.6 dual gig quicksilver.
You may want to fix this 'minor' problem

I noticed you're running a dual-gig quicksilver. Me too, I got bit bad by this problem, right at the time the MacFixit articled was out. I was a LW Pro user up to then, but I didn't renew.

And, FWIW, I've been playing with Acquisition for a month or so. Version 0.966 never gave me a problem, but a day after trying 97.1 (one version later), which "synchs with the latest LimeWire core," I now have a new overlapped extent allocation.

Anyway, since we both have dualies, I wonder if it's a CPU contention issue?