How to transfer OS to a new drive but preserve current data?

July 23, 2012 5:47 PM

How can I go about transferring my OS to a new SSD but leave my other programs without totally breaking everything?

My current system has my Win7, program files, documents, etc all on one drive. I picked up a SSD with the intent of moving my OS there (let's call it C:) but still having my program files (lots of steam games - maybe 120GB that I don't want to redownload) and whatnot on the original drive (let's call it D:). What is the easiest way to do this without losing all kinds of links/references/etc?

These are the options I can think of:

1) Install Win7 on the new blank drive and boot from it; mount D: as a slave and remove all the old OS stuff from it, effectively making it a storage drive (as it should be). Somehow I'd need to tell the new C: Win7 to use the program files on the D: drive, not sure how to do that.

2) The D: drive has less stuff on it total than the C: drive. I could make an image of things as they are now, image it to the C: drive, then restart the computer as if nothing has changed. At that point, how do I remove all the stuff from C: that I want on D: (which will still be on D:) and make sure the OS finds it?

3) _.,-~"~-,._ MAGIC! _.,-~"~-,._

Any help is greatly appreciated :)

posted by _DB_ to computers & internet (11 answers total)

Just my first thoughts here, but isnt one of the main points of getting a SSD that you could take big programs (like games) that take a while to load, and then loading them from the SSD would take much less time.

If both drives are mounted to the computer together, I dont see any reason that you couldnt just put your programs folder on another HDD. Option 1 sounds about right to me, but the problem would be that after you install win7 on the SSD you would have to reinstall all the applications, and just tell them to place themselves on the other drive. Because of the way windows is structured (woot registry) your not going to be able to use the pre-installed programs from the old operating system drive.
posted by KeSetAffinityThread at 6:02 PM on July 23, 2012

What you are trying to do a highly unorthodox. You have little chances of getting it to work unless you know what you are doing. Read a lot before making changes, and make sure you have ample backups with you.

Option #1 you proposed won't work, at least, not without reinstalling the programs. A large part of the information that's needed to run your program are set into the Windows registry when you install a program. If you install Win 7 from scratch, you are creating a new registry without all that information.

You can achieve Option #2 using Windows' "Volume Mount Points". Here are a few resources about mount points to get you started: Stackoverflow, technet.microsoft.com
posted by gmarceau at 6:06 PM on July 23, 2012

You could use Steam Mover to move the games after you've imaged the drive.

I also successfully used a symbolic link to move my Users folder to a data drive. You could probably use the same method for your Program Files folder.
posted by sockpup at 6:37 PM on July 23, 2012

Ah, Win7. I did this recently from an ancient 500G Barracuda to a 240G Mushkin Chronos. You want to uninstall programs that you don't use and/or can install easily again. You'll also want to move all "data" to someplace else. You want to reduce the "used" space of the current boot drive to less than the capacity of the new SSD. A 120G SSD only has 1,200,000,000 bits (check my math, but anyways) so it's only about 1.17GB(ytes).

My first Chronos might have been a bad one, but I went and aligned the replacement first.

Ran CCleaner (free) on the current boot drive; some IE temporary files and other weird stuff gets tagged as no-delete or something. Helps the defrag programs work better.

Used DiscWizard (free) from Seagate (works for any brand of drives).

Wouldn't fit (fragmentation). Used Defraggler to try to make everything contiguous within 240G. Couldn't get a weird sector out in the 400G range to move, even with the boot/offline method. Ran the Puran Defrag in boot/offline mode. Still didn't do the job. Ran Defraggler again, afterwards in boot/offline - and it worked! Both programs will visually present where sectors are located; if there's an occupied sector beyond 240G, you're going to have to try to move that sector's information.

DiscWizard made a perfect copy. After physically replacing the boot drive with the newly cloned SSD, adjusted it to max size through Win7 Drive Management control panel.

Loving the SSD.
posted by porpoise at 8:31 PM on July 23, 2012 [1 favorite]

Oh, if you're worried about game data, most modern games - when you uninstall through the Control Panel->Uninstall it'll ask you whether to save game data or not. Select not. When you reinstall the game, it'll be able to access all of your extant saved data.

So, if you reinstall from Steam to another (D -HD) drive, it'll still access the saved data in your (C -SSD) drive, and this should be seamless if you've been using default installs (so the program knows where the files are expected to be).
posted by porpoise at 8:35 PM on July 23, 2012

I have my home machine set up sort of like this. Everything's working fine, and it took a lot of tinkering.

If your new SSD is as big or bigger than the drive you have now, I'd really suggest just imaging it straight over as a first step. This $20 kit will make it a breeze. Yes, there are free software alternatives, but with this thing, you'll plug in your new drive, click GO and walk away for a bit. When it's done you swap the SSD in and enjoy it, then start messing with moving stuff off it onto a secondary drive if you decide you still want to deal with that.
posted by chazlarson at 9:51 PM on July 23, 2012

I know of no good way to do this. I have tried lots of ways. All of them cause trouble. None of them work as well as doing a fresh Windows installation on the new drive and fresh software installations onto the slave.
posted by flabdablet at 10:01 PM on July 23, 2012

Right. I should point out that on my home Windows 7 machine, with the OS on C: and various large directories moved to W: via junction points, many Windows updates are now failing with vague errors.

I imagine I would be well served to follow flabdablet's advice, but aside from the update issue everything's working fine, so so now I'm not really all that motivated to embark on that project.
posted by chazlarson at 10:45 AM on July 25, 2012

I don't know whether Windows 7 still does this, but Windows XP doesn't react well to having the "Documents and Settings" profile root folder moved to a different drive via a junction; among other things, any attempt to delete a file using Windows Explorer will fail (with a mysterious Access Denied error, if I recall correctly) unless you bypass the Recycle Bin.

This is because the Recycle Bin works via rename (intra-filesystem move) operations, with each drive having its own Recycler folder, and Explorer simply looks at the pathname of the file to be recycled in order to work out which drive's Recycler folder to use. So even if a junction at "C:\Documents and Settings" means that "C:\Documents and Settings\flabdablet\My Documents\recycle-me.txt" is in fact on drive D:, Explorer will still attempt to rename it into a subfolder of C:\Recycler and this fails.

The same effect is behind those random update failures. One of the mechanisms Windows uses to replace in-use files during updates is to defer the replacements until the next boot, at which time the replacement files will be renamed into place. If the temporary folder where Windows holds the replacements isn't part of the same filesystem as their final destination because of junction tricks, the boot-time renames will fail and break the updates.

Updates that can be done immediately without involving the deferred rename mechanism would presumably be unaffected.

Even without junction tricks, having the profile root folder on a different drive from %ProgramFiles% can cause issues. I once set up a little flock of classroom computers with "Documents and Settings" allocated on drive D: at Windows installation time, and found that Panda Cloud Antivirus wouldn't update properly on those. It turned out that the updater was using a subfolder of %ALLUSERSPROFILE% (which is itself a subfolder of the profile root) to hold boot-time replacements for components installed under %ProgramFiles%, meaning that at boot time there would be a doomed attempt to rename some files from drive D: to drive C:.

I wrote a little script to work around that fault until Panda fixed it properly in version 1.3. As it stands, that script does the same kind of pathname examination as Explorer does to identify the drive that a file is on. But if you have a bunch of Windows installations where you've done clever junction tricks, and updates are failing because of this issue, and you'd rather try working around it than doing re-installs, all you should need to do is make its Drive() function a little smarter.
posted by flabdablet at 9:45 PM on July 25, 2012

>the boot-time renames will fail and break the updates

Yeah, that makes sense. However, in most of these cases the failure happens in Windows Update before any reboot. Maybe the same rename-into-final-location thing is going on there.
posted by chazlarson at 9:50 AM on July 26, 2012

Oh, and thanks for the script.
posted by chazlarson at 9:51 AM on July 26, 2012