C
cquirke (MVP Win9x)
Assertion: The only way to preserve an XP installation (if you need to
change HD) is via partition imaging.
I'd love to hear that this was not the case (i.e. that a file-level
copy could work) but that's been my mileage so far. In that respect,
XP is considerably less robust than Win9x.
I've used BING to do this, and consistently find the resulting primary
on the new HD doesn't boot, even after any/all of:
- FDisk /MBR
- Recovery Console FIXMBR
- Recovery Console FIXBOOT
The problem is at the NTLDR level, or before; i.e. there's no Boot.ini
processing, so you can't boot (say) a resident DOS mode instead.
What fixes the problem is to resize the partition using BING, and then
size it back again. It seems as if this correctly regenerates some
information that's bent otherwise. As these are primaries often built
with BING in the first place, I don't think it's "too many cooks".
I also notice that BING's FAT32 cluster size rollover points (at least
at 8G) differ from those of FDisk. I can create a larger sub-8G FAT32
primary in FDisk than BING, and if I size such an edge-of-limit
primary down and up again to the same size, BING uses 8k rather than
4k clusters. BING's practical 4k-cluster FAT32 max is 8181M.
Has anyone else seen this? I suspect a relationship between BING's
different cluster size rollover threshold and non-bootable image copy.
change HD) is via partition imaging.
I'd love to hear that this was not the case (i.e. that a file-level
copy could work) but that's been my mileage so far. In that respect,
XP is considerably less robust than Win9x.
I've used BING to do this, and consistently find the resulting primary
on the new HD doesn't boot, even after any/all of:
- FDisk /MBR
- Recovery Console FIXMBR
- Recovery Console FIXBOOT
The problem is at the NTLDR level, or before; i.e. there's no Boot.ini
processing, so you can't boot (say) a resident DOS mode instead.
What fixes the problem is to resize the partition using BING, and then
size it back again. It seems as if this correctly regenerates some
information that's bent otherwise. As these are primaries often built
with BING in the first place, I don't think it's "too many cooks".
I also notice that BING's FAT32 cluster size rollover points (at least
at 8G) differ from those of FDisk. I can create a larger sub-8G FAT32
primary in FDisk than BING, and if I size such an edge-of-limit
primary down and up again to the same size, BING uses 8k rather than
4k clusters. BING's practical 4k-cluster FAT32 max is 8181M.
Has anyone else seen this? I suspect a relationship between BING's
different cluster size rollover threshold and non-bootable image copy.
Trsut me, I won't make a mistake!-------------------- ----- ---- --- -- - - - -