BING'd an XP to new C:, won't boot?

This is a "voodoo" tip, i.e. I know it works, but I can't explain why (oh sure, I can guess for days, but... I'd love to see "feedback 1" and read the answer!)

Here's what happens:
- use BING to copy an XP installation C: from one hard drive to another
- put the new hard drive into the XP installation's original PC
- diskette boot into DOS Mode
- FDisk /MBR to that standard MBR code in place [*1]
- FDisk option 2 to set primary C: as active to boot
- attempt boot into XP from hard drive
- fails with Disk Error
Now comes the "voodoo"...
- boot into BING, partition maintenance (no need to install BING)
- resize C: downwards a few megabytes
- attempt boot into XP from hard drive
- now this works fine
- boot into BING, partition maintenance (no need to install BING)
- resize C: back to original size
- attempt boot into XP from hard drive
- now this still works fine

[*1] FDisk /MBR caveats! This command replaces the Master Boot Record code with standard MBR code, overwriting whatever was there. That's bad in two situations:

• Non-standard MBR code was required, e.g. boot manager, boot virus, DDO code a la Max Blast, EZ IDE, etc. to work around BIOS limitations
  
  
• No valid 55AAh boot signature was present in the MBR; in such cases, FDisk /MBR will irreversably zero out the entire partition table, losing all partitions!

I've saved off the MBR and PBR and compared them; no differences other than the cached free space value etc. in 3rd sector of FAT32 PBR. So whatever BING is changing after a size nudge is within XP's file set or file system structure, and it's something that BING fails to do (or does wrong, perhaps different PC is a factor) when it did the partition copy.

The next part's also required, but isn't voodoo (as in the classic man, wife, secretary cliche; "I can explain everything" - but won't ):
- diskette boot to DOS mode
- Norton Disk Edit with writes enabled (we're about to "go boldly...")
- copy the pre-code bit from first sector of PBR
- paste this into the corresponding area of C:\BOOTSECT.DOS

Chances are if you're up to speed to do the above safely, you'll understand why you may need to do this if you want a formerly-working hard drive based Boot.ini-mediated DOS mode to work on the new hard drive. Repeat the same procedure to get a hard drive based Boot.ini-mediated Recovery Console to work, substituting C:\BOOTSECT.DAT for C:\BOOTSECT.DOS in the above example.

Today's Google: "this is where your sanity gives in, and love begins"

I've seen a video version of that which is built up entirely of scenes from the movie "Ghost in the Shell". If you've seen the movie, then the video brings it all back in 4 minutes... stunning!

Today's Bonus Google: "scuse me while I kiss this guy"

I wonder why HTML is so ^%$% useless with white space? What you see is hardly ever what you get, even within preview and view within the same program - all too often, contiguous white space is ripped out. This makes it difficult to space out multi-line bullet points, apply the convention of two spaces between sentences, and do ad-hoc bullet points.

I'd also like to know why this editor is so useless at applying a font consistently over a selection of text, and why all HTML editors fail to apply font choice to the numbers of numbered lists. The latter smells like another blind spot within HTML itself. Gah!