Eh, don't worry, it's only 0.0004%.
We make a product that, during the course of it's work, does a bit 'o disk partitioning. On Intel hardware (which uses the newer GUID Partition Table), Apple has defined a 128 megabyte "gap" partition that is created after any partition on large-enough disks. If you're a developer writing code that will be manipulating the partition table, you usually want to ensure that you stick exactly to the "letter of the law"; in this case, whatever Apple does is all the truth and justice you need. As diligent developers, our software respects this gap when creating the partition(s) it needs.
But when Leopard was released, we kept getting tech support calls exclaiming that any machines that had been partitioned using our software were failing to install the new OS successfully. Days went by and our QA couldn't reproduce it; then someone from Apple calls directly. Turns out it was our code: the gap partition we created was inexplicably one block too small. Since hardware block size is 512 bytes, and the gap partition is 128 megabytes, this accounted for a discrepancy of but 0.00038% of the total bytes in that gap partition.And it was hosing people's machines. Update: turns out the symptom was unwanted behavior in the installer (informing users they had to reformat their drives, something most didn't want to do) rather than actual data loss. Still, no good.
An effort was launched to track down the problem, and after pouring through code that no man should have ever put to disk in the first place, the offender was found.
As it all too often turns out, the problem was minor miscalculation in a small part of a larger calculation to determine the starting and ending addresses for the new gap partition. Considering that these "gap" partitions are just that, blank gaps left there to ease future software development, we were apparently getting by with the fact that no system app or installer actually checked to ensure these gaps were of the "required" size.
That is, of course, until the Leopard installer. In which Apple decided, for the first time, to check and enforce the size of these partitions, causing the installer failures we've been hearing about constantly lately. All because our code calculated 262,143 when it really meant 262,144.
If you've ever skimped on testing a bit of code where you thought an off-by-one bug might be lurking but weren't sure, hopefully now you see how much harm even 0.0004% can cause. (Especially when you're writing dangerous code to muck with partition tables directly!) Just imagine what would could have gone wrong if the offending code had been in a more sensitive or destructive algorithm than it was...
But when Leopard was released, we kept getting tech support calls exclaiming that any machines that had been partitioned using our software were failing to install the new OS successfully. Days went by and our QA couldn't reproduce it; then someone from Apple calls directly. Turns out it was our code: the gap partition we created was inexplicably one block too small. Since hardware block size is 512 bytes, and the gap partition is 128 megabytes, this accounted for a discrepancy of but 0.00038% of the total bytes in that gap partition.
An effort was launched to track down the problem, and after pouring through code that no man should have ever put to disk in the first place, the offender was found.
As it all too often turns out, the problem was minor miscalculation in a small part of a larger calculation to determine the starting and ending addresses for the new gap partition. Considering that these "gap" partitions are just that, blank gaps left there to ease future software development, we were apparently getting by with the fact that no system app or installer actually checked to ensure these gaps were of the "required" size.
That is, of course, until the Leopard installer. In which Apple decided, for the first time, to check and enforce the size of these partitions, causing the installer failures we've been hearing about constantly lately. All because our code calculated 262,143 when it really meant 262,144.
If you've ever skimped on testing a bit of code where you thought an off-by-one bug might be lurking but weren't sure, hopefully now you see how much harm even 0.0004% can cause. (Especially when you're writing dangerous code to muck with partition tables directly!) Just imagine what would could have gone wrong if the offending code had been in a more sensitive or destructive algorithm than it was...