Miles Johnson

Upgrading My Desktop: Migrating Programs and Hard Drives

The next step in my system upgrade was to install and format the new hard drives, migrate all program files over to the new drive, and setup symlink's for legacy paths. For my upgrade I was installing a 1TB internal HD that will house all my program and game installations, and a 128GB SSD that will house the Windows 7 OS. This process was pretty tedious, so bare with me and follow closely.

1) Installing and formatting the new hard drives

The first thing I had to do was physically install the hard drive into my computer (of course), connect any SATA and power cables and make sure it was fastened in the HD bay slot. Once installed and the computer turned on, I opened the Computer Management program; you can locate this program by searching for "computer" in your start menu search.

Selecting the Disk Management tab on the left should populate with all the installed drives. If your newly installed drive does not show up, shutdown your computer and diagnose the problem by checking that all cables are connected correctly. Otherwise, right clicking on the drive allows you to format and create a partition (or volume) by selecting the New Simple Volume Wizard.

When formatting my drives, I used the default volume size as I was only creating 1 partition per drive. When it gave me the option of selecting the drive letter, I chose E: for my 1TB HD and opted out of using a letter for my 128GB SSD, as I will be replacing my old C: with the SSD.

Lastly, in the format partition dialog, I chose NTFS as the file system (this is critical) and the non-quick format option. I didn't use the quick format as I wanted to stay on the safe side and ensure that everything was erased and cleaned (even though it was a new drive).

Restart the computer when the formatting is done (I restart a lot).

For a more in depth guide on this process, checkout the following articles:

• Installing a new drive
• Formatting a drive

2) Uninstalling current programs

The next big step was to uninstall all my programs. I am not too positive this is necessary compared to dragging the current Program Files folder over to the new drive, but I uninstalled and reinstalled all my programs to validate they all have the correct paths in the registry, startup, configuration, shortcuts, targets, etc.

Note: During the uninstallation process, be sure to keep all saved data and settings if the program gives you the option. Since I was not doing a clean install of the OS, the AppData and related folders will continue to persist all my program settings and cache once I reinstall it.

When all available programs were uninstalled, I restarted my computer.

3) Overriding the Windows registry

Now this is the first important piece. Changing the Windows registry that points to the Program Files path allows any program to automatically install to the new location (on the new drive) without me manually having to define it. However, some programs are just plain idiotic and will still set the path to C:/Program Files/ instead of the new path.

For reference, here are my old and new system paths:

C:\Program Files\		-> E:\Programs\
C:\Program Files (x86)\	-> E:\Programs (32)\

Additionally, I added the following folders on my E: drive:

E:\Backups\		Location of system restores and backups
E:\Data\		Temporary file and cache location for Programs
E:\Games\		Installation path for all games (separate from regular Programs)
E:\Installers\	Program installer executables (I like to save them)
E:\Tools\		System tools like Process Explorer and SIW

After the uninstallation process, I continued to find programs left over in the C:\Program Files and C:\Program Files (x86) folders. These leftovers are more than likely Windows related programs and should be left alone for now. Do not delete these programs nor delete the parent folder.

The next step was to edit the Windows registry. You can open the registry editor by typing "regedit" in your start menu search and pressing enter. In the editor, drill down into the following path: HKEY_LOCAL_MACHINE -> SOFTWARE -> Microsoft -> Windows -> CurrentVersion

Click on the CurrentVersion folder -- this is where we will edit the program files paths. I modified the registy by changing the following fields to the new paths (note the non-trailing slash):

CommonFilesDir			-> E:\Programs\Common Files
CommonFilesDir (x86)	-> E:\Programs (32)\Common Files
CommonW6432Dir			-> E:\Programs\Common Files
ProgramFilesDir			-> E:\Programs
ProgramFilesDir (x86)	-> E:\Programs (32)
ProgramW6432Dir			-> E:\Programs

After a compute restart, any new program installations should install to this new location.

4) Installing and migrating programs

This part is pretty easy, I simply re-installed all the programs back onto my computer. If the installer gives you the option to do a custom install (allowing you to choose the install location), select it. This allows you to verify the program is installing to the new path and is a required step as some programs will still attempt to install to C: -- if this happens, just change the path yourself.

When all program installations were complete, it was time to migrate the leftover programs. All I did was select and copy all the folders in C:\Program Files and paste them into E:\Programs. I also did the same by copying all folders in C:\Program Files (x86) and pasting them into E:\Programs (32).

Probably the easiest step in the process, but also the most time consuming.

5) Legacy folder cleanup

Before symlink's can be created, the origin folder must not exist. The next step I had to take was deleting the old C:\Program Files and C:\Program Files (x86) folders... which turned out to be quite difficult. Doing a delete or shift + delete didn't work as I would get basic access denied alerts. I then switched over to the command prompt to attempt some deletion magic... the following did not work.

"rd" - This command *should* remove a directory and all files within. Still received access denied errors.

rd /S "C:\Program Files"
rd /S "C:\Program Files (x86)"

"takeown" and "icacls" - These commands basically change the ACL (access control) of all files and folders, and give ownership to the Administrators group (This is basically the same as changing ownership in the right click properties dialog). This also did not work.

takeown /f "C:\Programs Files" /r /d n
icacls "C:/Programs Files" /grant Administrators:F /t
takeown /f "C:\Programs Files (x86)" /r /d n
icacls "C:\Programs Files (x86)" /grant Administrators:F /t

Now after many hours and much frustration, I was ready to give up. But after much Googling, I found the answer -- it was time to bring out the big guns. The following did work. This command enables the hidden Administrator account on all Windows Vista/7 systems.

net user administrator /active:yes

Once enabled, I switched over and logged into the Administrator account. I was now able to shift + delete the folders with no problem. When deleted, I logged off the Administrator account. Running the following command disabled the account.

net user administrator /active:no

Easy right? I thought so as well.

6) Setting up symbolic links

The final step -- never thought I would get this far. Seeing as how I have successfully installed a new hard drive, migrated all programs over, modified the Windows registry and cleaned up legacy folders, it is now time to setup symbolic links. Like I stated before, symlink's are a way to have anything that points to the C: drive, reference the same files within the E: drive. The same goes for writing data -- anything written to C: is actually being written to E:.

Note: Since I named my programs folder E:\Programs instead of E:\Program Files, anything referencing C:\Program Files will not find a symlink match. However, I have yet to run into any problems after weeks of testing.

Setting up the symlink's was easy:

mklink /D "C:\Program Files" "E:\Programs"
mklink /D "C:\Program Files (x86)" "E:\Programs (32)"

Tada, magic! I now see a shortcut within C: that references E:.

Conclusion

It took me hours over the course of a couple days to do all of this. The hardest part was Googling around for solutions as many of them lead to dead ends. It also helped me figure out problems during the migration as I would run into weird cases where startup items would fail, or programs could not be located. Most of these problems disappeared once symlink's were created.

I've been using this new setup for a couple weeks now (at the time of writing this) with no problems. I have yet to switch over to the SSD however... so that should be interesting.

Codebase Upgrades: Upgrading Uploader v2.8 to v3

The Uploader plugin has upgraded major versions from 2.8 (CakePHP 1.3) to 3.0 (CakePHP 2). Since this is not a backwards compatible change, the 3.0 version can only be used in CakePHP 2.

No more UploaderComponent

During the conversion process, the primary change is that the UploaderComponent was removed and turned into a stand-alone vendor class. This was done to further encourage the use of the AttachmentBehavior. Because of this change, you will need to manually initialize the Uploader in your Controller::beforeFilter() (only if you were using the component). The property settings are now passed as an array through the constructor.

// Before
public function beforeFilter() {
	$this->Uploader->tempDir = TMP;
}
// After
public function beforeFilter() {
	$this->Uploader = new Uploader(array('tempDir' => TMP));
}

By instantiating the class to $this->Uploader, all of the old code should still work as normal. This change also allows the possibility to use the Uploader anywhere in the application.

No more S3TransferComponent

The S3TransferComponent was trying to do something it shouldn't have. The component was removed in favor of the Vendor/S3 class that provides far more functionality. The AttachmentBehavior has also been updated to use the S3 class instead of the component.

Certain methods are now static

The bytes(), addMimeType(), checkMimeType(), mimeType() and ext() methods are now static.

Those should be the only changes you would need to make to support the new version. There are quite a few other changes, so be sure to check out the changelog and to also check out the updated documentation.

Codebase Upgrades: Upgrading AutoLogin v2.2 to v3

The AutoLogin component has upgraded major versions from 2.2 (CakePHP 1.3) to 3.0 (CakePHP 2), now 3.1. Since this is not a backwards compatible change, the 2.0 version can only be used in CakePHP 2. During the conversion process, many things had to change to support the new AuthComponent.

No more automatic username/password field detection

Previously AutoLogin would detect the custom name of your username and password fields by accessing Auth::$fields. Since that property has been removed in favor of Auth::$authenticate, the AutoLogin component received a new property called $fields which mimicked what the Auth's version did. I didn't want to magically guess what the username and password is from Auth::$authenticate and be wrong, so I made it an optional property (you should only need to change it if you are using custom fields).

$this->AutoLogin->fields = array('username' => 'user', 'password' => 'pass');

Seeing as how that was the only major change that may require backwards support, the following minor changes have also occurred: CakeRequest has been implemented anywhere $params were being referenced, the user model is detected via Auth::$authenticate (all first, then Form) in place of the deprecated Auth::$userModel and cookie support has been implemented for localhost environments (may not work in all environments).

If you have any questions, or run into any problems, let me know!

Codebase Upgrades: Upgrading AjaxHandler v1.6 to v2

The AjaxHandlerComponent has upgraded major versions from 1.6 (CakePHP 1.3) to 2.0 (CakePHP 2). Since this is not a backwards compatible change, the 2.0 version can only be used in CakePHP 2. During the conversion process, many other features were refactored or removed, here is a quick round-up.

No more automatic data gathering

In the older versions, any request data was gathered and merged into the Controller::$data property within AjaxHandler::startup(). This is no longer the case as I highly suggest using the new CakeRequest class to manipulate data in your AJAX action. This class can be accessed at Controller::$request.

No more content type restrictions

Previously you could only respond() an action using JSON, HTML, XML or text. Now you can respond using any content type defined in CakeResponse. Automatic JSON/XML formatting is still enabled.

Removed the valid() method

The valid() method was a very abstract and useless method that simply checked that strings or integers were not empty. The AjaxHandler should not be dealing with any validation (low level ones even more so), so it was removed. Please integrate your own data validation.

Besides the major changes listed above, any private class properties were converted to protected visibility, to allow class extension and the RequestHandler was replaced with CakeRequest in most situations, ala is('ajax') compared to isAjax().

If you have any questions, let me know!

The flawless upgrade to Cake 1.3

Cake 1.3 has been around for quite some time now, but I never had the desire to upgrade with it being in such a beginning stage. Well seeing as how its now in Alpha and many users are testing it with no problems, I thought it would be a good idea. The project I was going to upgrade is quite large, heres a quick rundown of just how large:

19 controllers, 8 components, 15 locales, 64 models, 2 plugins, 6 vendors, 8 stylesheets, 14 javascripts, 7 helpers, 159 views

This isn't counting the admin panel, which is a whole separate app, and which I have not upgraded yet. Now lets get onto the upgrade, its probably the easiest thing to do. All I did was follow the migration guide. First off was checking to see if I used any deprecated methods, which was simple, all I did was search the whole app folder for words like del(. I was surprised to find I used it like 5 times, when I always preferred the full delete().

Next in the list was upgrading to the new Router conventions, which lucky for me didn't apply. I never used any non basic conventions, I mean why would you! One thing that bugged me though is the new page title implementation. It took me quite a while to go through all those controllers, and all the actions within them. Another nuisance was adding "echo" to all the flash() calls in the views, and removing the "inline" parameter from all meta() and css() calls, but wasn't too time consuming.

One of my most favorite updates was the new pagination support with passedArgs. I had to hack all my paging before, but in the new update I removed it all and it worked wonderfully! Thanks Cake team :]

All in all, the upgrade went smooth. If you follow Cake conventions all the way through, you don't need to do much alterations. I for one am looking forward to the future versions.