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.



>-------------------- ----- ---- --- -- - - - -
Trsut me, I won't make a mistake!
>-------------------- ----- ---- --- -- - - - -

Post in BING's newsgroup and the developer of BING will answer all your
questions and/or get things on the right track.

"cquirke (MVP Win9x)" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> 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.
>
>
>
> >-------------------- ----- ---- --- -- - - - -
> Trsut me, I won't make a mistake!
> >-------------------- ----- ---- --- -- - - - -

On Fri, 26 Mar 2004 08:30:34 -0500, "Ed." <(E-Mail Removed)> wrote:

>Post in BING's newsgroup and the developer of BING will answer all your
>questions and/or get things on the right track.

That sounds good - what's the name of the ng? Not sure if my ISP
carries it, etc. and I wouldn't want to post somewhere I can't get
back to read. Maybe if I x-post to the ng? :-)

>"cquirke (MVP Win9x)" <(E-Mail Removed)> wrote in message

>> I've used BING ... 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 NTLDR level, or before; i.e. no Boot.ini processing
>> 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.

>> 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.


>-------------------- ----- ---- --- -- - - - -
Running Windows-based av to kill active malware is like striking
a match to see if what you are standing in is water or petrol.
>-------------------- ----- ---- --- -- - - - -

You can go here:

http://www.terabyteunlimited.com/support.html

Scroll down "TeraByte Sponsored Newsgroups"
It will give you info on it. Click on the "click here" link for how to set
it up.

I use the products and I think what you need to do is change the partition
number in the boot.ini file.

"cquirke (MVP Win9x)" <(E-Mail Removed)> wrote in message
news(E-Mail Removed)...
> On Fri, 26 Mar 2004 08:30:34 -0500, "Ed." <(E-Mail Removed)> wrote:
>
> >Post in BING's newsgroup and the developer of BING will answer all your
> >questions and/or get things on the right track.
>
> That sounds good - what's the name of the ng? Not sure if my ISP
> carries it, etc. and I wouldn't want to post somewhere I can't get
> back to read. Maybe if I x-post to the ng? :-)
>
> >"cquirke (MVP Win9x)" <(E-Mail Removed)> wrote in message
>
> >> I've used BING ... 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 NTLDR level, or before; i.e. no Boot.ini processing
> >> 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.
>
> >> 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.
>
>
> >-------------------- ----- ---- --- -- - - - -
> Running Windows-based av to kill active malware is like striking
> a match to see if what you are standing in is water or petrol.
> >-------------------- ----- ---- --- -- - - - -

On Fri, 26 Mar 2004 19:58:17 -0500, "Ed." <(E-Mail Removed)> wrote:

>You can go here:

>http://www.terabyteunlimited.com/support.html

>Scroll down "TeraByte Sponsored Newsgroups"
>It will give you info on it. Click on the "click here" link for how to set it up.

I don't think my ISP carries those, and I'm disinclined to start a new
Free Agent data set just for this.

>I use the products and I think what you need to do is change the partition
>number in the boot.ini file.

That wasn't the problem (given the fix doesn't address that). I saw
something in the FAQ that mentions non-default OS installation paths,
which I have always routinely used. Maybe that's a factor?



>-------------------- ----- ---- --- -- - - - -
Running Windows-based av to kill active malware is like striking
a match to see if what you are standing in is water or petrol.
>-------------------- ----- ---- --- -- - - - -