If the drive uses a different controller which is not now visible in Device Manager, you will have a problem unless it looks transparently just like a standard controller, or XP has a built in driver for it, so getting such a driver installed before you change over is important.
XP identifies HDs (for itself) by doing some kind of computation which results in a long (presumably unique) hash code. You can see these codes in the registry at the key :
HKEY_LOCAL_MACHINE\SYSTEM\MountedDevices\
So even if you copy everything exactly to an IDENTICAL HD, XP can still tell the drive has been changed, and the first thing it will do after the first boot on the new HD is to reinstall that drive. If this is your fourth(?) change to the system, XP will want you to reactivate (which is not a problem.) The confusing problem comes if you have ever had both drives present with XP booted, ever. When you switch to the new drive, XP will want to give it its old drive letter. So what should be your C drive gets the letter D: (say) and your installed progams won't be found because the links refer to C, not D. Worse, you may get a stange error (about checking the license) and an unbootable XP, because XP will look for hundreds of its base components on the wrong drive letter which (insanely) is hardcoded into the registry for some components, but "relative" for others. This can be avoided by rewriting a certain spot on the HD before you boot. (Which the BootitNG program can do.) All that does, I gather, is make the drive look like one XP has not seen before. BTW, although reinstalling XP over itself will make it bootable again (because XP can find its own files), the drive letter will still be D:, and it doesn't fix the letter problem for installed programs.
My solution to changing to a new drive is to copy from drive to drive directly. You also need to put things on the HD which are outside a file system, namely a MBR, and boot sectors on the first partition (and boot sectors on the linux partitions too, if that's how you boot linux. ) Fixmbr and fixboot do this under XP's Recovery Console.
Before going into all the things which don't quite work, I''ll just say that BootitNG did it right. BootitNG does not need any OS. It is its own. BootitNG can be put on a floppy or burned to a CD. Within BootitNG, just copy a partition on one HD and paste to unallocated space on another (or the same HD if you like.) You don't partition first in order to copy. It will resize or slide partitions ( FATxx, NTFS, linux ext3, and others.) It seemed to copy the boot sectors, in addition to all files, at least if you select the option to copy everything, not just data. It can also create/restore images and save them to a HD, or burn them to CDs or DVDs, all without an OS on the HD (although I've never used those functions.) And it has a few more tricks too.
I have 16 partitions on my HD, 5 of them linux, 2 NTFS.
Here is more about HDs that you never wanted to know. And which I wish I never had to find out!
MaxBlast (which came with the HD) did not copy the partitions in a way that they worked without oddities. For instance, the Programs menu had lots of items indicated as newly installed, although most of them were installed long ago. Doesn't make sense. I therefore did not completely trust the result. Maxblast copies files into partitions afer you create the partitions. I took me roughly 45 minutes to copy 8 G. It did not put the boot sectors on. It doesn't do any linux at all, not even marking them as linux. Automatic partitioning only used the HD space up to the 137G line, when the HD is 160G. This, despite the fact my BIOS, stc., is fully capable over 137G, and Maxblast tells me it is.
Partition Magic 8 (up-to-date) gave me errors and never copied a partition. After I set everything the way I wanted it in Windows XP, PM8 rebooted to a version of DOS to do its work. It spent 20 or so minutes where it looked exactly like it was copying the first partition (8 G) and then when it was tidying up at the end, gave me an error, and stopped. I never found a way to make it do anything beyond this, and I verified that in fact no files were on the new HD. My main tool in seting up my old HD WAS PM7, as I recall, so I don't get it at all. The capabilties and ease-of-use of the DOS PM8 are pathetic next to BootitNG.
Casper XP, which works entirely within XP, said there was something amiss with my old HD, making partitions uncopyable to the new HD, but offered to copy files from one drive letter to some other. I tried that, but when the transfer time for 8 G indicated 19 hours, I let it run for a half hour, until it became clear that the prediction was correct. Copying 8 G by drag and drop in XP takes about 15 minutes on my hardware (except that XP aborts when it hits even one snag, which is normally the case for the boot partition.) So I never found out if Casper really does have some way of working around the uncopyable files that subvert the drag-and-drop method.
OK, so there is something strange about my current HD (evidently), although I don't know what, and no program will say what. I have confirmed many times over that the drive does not have a drive overlay.
On to linux and PARTED. Like all linux things, it take some figuring to get it to work, but turns out to be rather easy if you just knew what you had to do. It happens there is a copy of PARTED on the Redhat 9 install CD (but not on the Mandrake install CD) and you can get a linux prompt from the CD. PARTED said it lacked the capabiltiy to copy the Red Hat or Mandrake linux partitions, but it did copy a linux data partition and a partiton which just has a linux boot loader. (PARTED wants the partitions it copies unmounted, so I tried that.) It won't do NTFS, except to mark the partitions as NTFS. But it copied all the FAT32 partitions perfectly, without the working oddities I got with Maxblast. PARTED can resize the partiitions it understands.
There is a linux Fdisk, which has partitioning functions. But Fdisk said it was "deleting" partitions beyond 16. The way linux numbers them, I have too many (a partition hda17 and hda18) so I didn't dare use Fdisk for anything but looking.
I thought I could copy all the Mandrake files to the new HD while booted to Red Hat (and visa versa.) by doing a cp * (unix copy) to and from the appropriate mounts. Well, all the files copied without reported errors alright. But, neither OS entirely worked from the new HD. For instance, I got "-bash: dev/null: Permission denied" when I logged onto Mandrake. And I got nothing but long timeouts and errors when starting X to get into the GUI. I couldn't start X logged on as root either. But the directories and files all seemed to be present.
I tried to fix Red Hat on the new HD by doing a reinstall over it from the CD, but the installer program crashed and aborted when it go to the point of copying files. (Something unexpected on the partition, no doubt.) The corresponding procedure for Mandrake could not find any Mandrake installation on the HD.
Unexpectedly, I found no way to copy linux using linux. OTOH, linux is great for copying FAT32! BootitNG copied Mandrake and RH pefectly to the new HD, including their boot sectors. It takes about 25 minutes for 8 G.
The fastest way of transfering files from one HD to another turned out to be copying them from within Windows., copy-and-paste or drag-and-drop. Since I have several installations of XP on the HD, I can boot into the one on E: (say) and copy the one on C: to the new HD without snagging and aborting on some files that are in use. Maybe one shouldn't copy the "System Volume Information" directory onto drives after the drives have files on them, and copying the huge hiberfil.sys and pagefile.sys are unnecessary. But I found some strangeness when copying files on an NTFS to an NTFS, while booted to an XP installed on a FAT32. One set of uncopyable mysteries are files compress by virtue of having a compressed attribute set. They wouldn't copy apparently because this compressed function was not available while booted to the FAT32 installation. Those files copied without hesitation while booted on an NTFS installation (although they became uncompressed on the drive copied to!) There were two other mystery aborts, one was in a "Documemts and Settings" subdirectory for my longin name. It turned out to be an empty directory, not a file. The files within the directory could not be accessed, and therefore the copy aborted, but there were no files there to copy anyway. The other was in a subdirectoy of Cygwin ( a unix like module that operates under XP/NT.) I can't imagine why I couldn't view the file or copy it, but I was permitted to delete it, which got me passed that snag. (It had a .tmp extension, so I figured it was OK to delete.)
Facebook
Twitter