Bringing my External Hard Drive Back to Life

Last Monday I wrote about restoring access to an outdated subversion repository after the hard drive in the computer that was being used as a subversion server died. That was my second hard drive failure of 2009, but at the time I thought it was the third. It turns out that what I had thought was my second failure, the failure of the external drive that I use for backup and random storage, was in fact a case failure. The drive is fine, and it is once again functional in a doctored case.

The drive in question is a 500GB Trekstor Datastation maxi m.u that I got at a boxing day sale at Future Shop a couple of years ago. As many Canadians know, when something from Future Shop dies you’re pretty much on your own to fix it, so that’s what I did. When the drive stopped working I googled it and discovered that a lot of people have had problems with the power supply to the drive. Some have been able to fix the problem with new power adapters, so I tried using an all-in-one adapter that I had, but the drive behaved as it had with its own adapter. Ever hopeful, I opened up the case and brought the drive to the in-laws’ place to test it, and when inserted into a computer it worked, so all I had to do was replace or repair my case and I would have my external hard drive back again.

I looked online at new cases, but it seemed like a waste to get a whole new case when the only thing that was broken was a small circuit board, so I found a stand-alone SATA to USB converter with no case and ordered that. When it arrived I tested it and it worked, so today I set about putting the drive back in the case, but with the new adapter. First, I removed the old electronics from the case. However, the holes that were in the back panel were not large enough for the ends of the cables of the new adapter.

The back of my hard drive case
None of the new cables will fit through these holes!

Out came the Dremel and most of the back panel was cut out to make room for cables & electronics. Once I had made the cut, cleaned up, re-mounted the drive, and re-attached the back plate, I had a good hole through which I could attach my shiny new adapter and keep the drive itself protected.

The back plate of the drive case has been removed.
That's better. I can reach through there.

My only complaint is that the USB cable on the adapter is a bit short, so I may have to get a hub or something to pretend it’s an extension able. For the moment I have just re-arranged my desk slightly.

The drive, in the case, with the new adapter attached.
The drive, in the case, with the new adapter attached.

* A note on image quality: My camera went missing a while ago, so the best I can do right now is the iSight built in to my laptop. Sorry!

How to Update an Outdated Subversion Repository from a Working Copy

Last week the hard drive on my Subversion server failed and I had to rely on my backups to bring up a new server.  My most recent backup was not 100% current, so I ended up with a Subversion repository at revision 935, but a working copy at revision 953.  This is the story of how to reconcile the working copy with the backup so that your latest work is once again in your repository, on a Mac.

First, I looked for a way to simply import my working copy, along with any version info that it might have, but that doesn’t seem to exist.  Then, I tried just committing a new revision to the repository, (it had the same URL as the one on the failed hard drive), but that lead to subversion errors.  It turns out, that if your working copy has a revision number that is higher than that in the repository, you need to check out a new working copy, then copy changes from your old working copy into your new one, the commit your changes to the new working copy.  It sounds easy enough, but there are a couple of gotchas to watch out for, like those pesky .svn folders, so here is a recipe for merging a working copy with an outdated repository, so that the repository is brought up to date:

  1. In your existing working copy, (I’ll call this the “old working copy” from now on), make sure that you’ve done an svn add for any files that are not yet under version control but you want to make the transfer.
  2. Check out a new working copy from the outdated repository, (I’ll call this the “new working copy”).
  3. On the old working copy, do an svn export.  This gets you all of your most recent files, but without any .svn folders in the mix.
  4. In Terminal copy the exported files into the new working copy by running the command cp -R exported_folder/* new-working-copy-folder
  5. [optional] Do an svn infosvn status on the new working copy.  It should show that you need to check in all of the changes you made since the repository was last updated, (or since your last backup).
  6. Commit the changes in your new working copy.   You are finished, (you might want to archive the old working copy at this point in case something didn’t work right).

Your new repository should now have the latest work in it from your working copy.  You will have lost the revision history between your latest backup and whatever you had in your working copy, but you won’t have lost it all, and you will once again be up and running and ready to code, (or write, or whatever).

Of course, you could avoid this whole hassle by making sure your backups are always up to date.

(Failing to) Find the Olympic Flame Online

Yesterday, I went out on Rue St-Denis to see the Olympic Flame pass by for the second time in my life, and I hope to see it again at some point. I also hope that next time it will be much easier to find out where to go to find the flame.

The 106-day torch relay for the 2010 Olympic games in Vancouver is a big deal here in Canada. It is on the news every day and is travelling 45,000 kilometres making a great loop around the country. Right now, with the games approaching but not right on our doorstep, the torch relay is the most important part of the olympics to me, probably to many Canadians. However, when I went looking on vancouver2010.com to see where I could find the torch I was thoroughly confused. It is easy to find out about every sport that will be played in 63 days time, but learn about the torch relay happening right now I had to dive deep into a pop-down menu, then take a guess at which icon would lead me to a map or description of the torch route.

These are the choices I had:

Which icon gets us to a map of the torch route?
Which icon gets us to a map of the torch route?

And this is the right choice:

Apparently this means "Map"
Apparently this means "Map"

The map should have been simple to read, after all, it’s a map with a route drawn on it. Just zoom in to see what’s going on near you. Well, good luck, when you zoom in too much the route disappears! It turns out that you have to choose your “community” then you can see a detailed map of what’s happening in that community. I’m not sure why this is, and it’s quite confusing. Once you’ve got your community selected, you may have to select different routes in your community, (the relay is less like a relay around the country and more like a travelling roadshow with some stops where people get out and run than I had thought), and you can see what time the flame will be in different places, in the HTC timezone, whatever that is.

I hear the games are over budget, but it would be a wise investment to put a direct link on the vancouver2010.com homepage to the map. There are lots of links to videos of previous days, and in truth they do sometimes link the Latest News block on the page to the map, but for me, when I went to the site, I was looking for a more permanent link to the torch relay information. After all, the torch relay is on for 6 times as many days as the games themselves.

I was lucky, I found where the torch would be, and was there at the right time, (for me HTC was Eastern Standard Time, but I don’t know if it is everywhere, maybe it just means Local Time). I hope everyone else who is looking for the map can find it.

In case you’re having trouble, here’s a link to the map.

And here is the torch, (I didn’t have a camera with me, so this is from Flickr:
The Torch in Montreal

Get your Development Server Running after Upgrading to Snow Leopard

After upgrading to Snow Leopard today I tried to access my localhost versions of the websites I have under development and was met by this great message, (impatient? skip to the step-by-step solution):

Forbidden

You don’t have permission to access / on this server.

Great. I couldn’t even access http://john-mbp/ – my computer’s name, and the URL that the System Preferences’ Web Sharing pane tells me I can access. However, all is not lost.

Part 1: Get the Virtualhosts Online

The first place I looked was my httpd-vhosts.conf file, located in /var/apache2/extra, (this has not changed since 10.5), and as I suspected it had been reset to the Apache defaults, (thanks Apple). I suspected this might happen though, and had made a backup of the file, (actually, I backed up my whole hard drive, then made a separate, easier to find, copy of the file). Replacing the new httpd-vhosts.conf with the old one and doing an sudo apachectl graceful got the virtualhosts responding to requests again.

Part 2: Establish a MySQL Connection

While my virtualhosts were up and running at this point they did not have a MySQL connection. Maybe this is because my MySQL installation is from MacPorts so the socket is in a different place, or maybe not. Either way it had to be fixed.

Upon running a phpinfo(); I discovered a couple of things. First, the included version of PHP is now 5.3.0 and second, PHP was not loading any php.ini file, so I went on a php.ini hunt and found 2 files: php.ini.default and php.ini.default-5.2-previous, both located in /etc. Copying php.ini.default to /etc/php.ini and doing a sudo apachectl graceful brought my MySQL connections back online, leaving one final problem.

Part 3: Getting rid of the timezone warnings

Since I usually code with an error reporting level of E_ALL, and PHP 5.3 doesn’t seem to like not having a timezone set in the php.ini file, (it’s not set by default, at least not in Snow Leopard), I was getting a bunch of warnings whenever I used the date(); function in PHP, so, I needed to set a default timezone in php.ini. If you don’t already know the PHP name for your timezone, go to the PHP timezones page and find it, then open php.ini, (sudo vi /etc/php.ini the sudo is important), and search for “timez” to find the timezone section of the file. Now, on the line that says “;date.timezone = ” add the name of your timezone after the equals sign and remove the semicolon from the beginning of the line. Once you’ve done that, save the file, (it’s set as read-only for some reason so in vi you need to do :w! to make it save), then quit your text editor and do one more sudo apachectl graceful and you should be good to go.

Step by Step

  1. before installing, back up your computer
  2. before installing, make a copy of /etc/apache2/extra/httpd-vhosts.conf and put it somewhere safe
  3. install Snow Leopard
  4. replace the new /etc/apache2/extra/httpd-vhosts.conf with the old one you saved in step 2. If you don’t have a backup you’ll have to re-enter your virtualhosts in the new httpd-vhosts.conf file which isn’t the end of the world
  5. in Terminal type sudo apachectl graceful and enter your password if prompted to restart apache with the new configuration. Your virtualhosts should now be online
  6. rename or copy /etc/php.ini.default to /etc/php.ini (sudo cp /etc/php.ini.default /etc/php.ini)
  7. Find the name of your PHP timezone, (look on the PHP timezones page). Write it down.
  8. Edit the new php.ini file to have the correct timezone.
    1. open the new php.ini file (sudo vi /etc/php.ini)
    2. find the timezone section, (type /timez and press enter).
    3. move your cursor to the line that says “;date.timezone = ” using the arrow keys
    4. press the i key to edit the text
    5. add the name of your PHP timezone after the equals sign
    6. remove the semicolon from the beginning of the line
    7. press the escape key to stop editing the text
    8. type :w! to save the file
    9. type :q to quit the text editor
  9. One final sudo apachectl graceful and you should be back up and running.

Getting MacPorts to work Snow Leopard

Impatient? Skip to the process and go right to the solution.

I’m writing this using my shiny new OS X 10.6 Snow Leopard installation. So far it’s pretty good. I haven’t tried any heavy lifting so I don’t know if it’s really that much faster.

This is the first in a series of posts on how to get things working in Snow Leopard that got eaten during the installation. First up: MacPorts.

I ran into some issues with MySQL, (more on that later), and since my MySQL install is a MacPort I thought I would do an update to make sure things were working properly. However, this is what happened when I typed sudo port list installed:

dlopen(/opt/local/share/macports/Tcl/pextlib1.0/Pextlib.dylib, 10): no suitable image found. Did find:
/opt/local/share/macports/Tcl/pextlib1.0/Pextlib.dylib: no matching architecture in universal wrapper
while executing
"load /opt/local/share/macports/Tcl/pextlib1.0/Pextlib.dylib"
("package ifneeded Pextlib 1.0" script)
invoked from within
"package require Pextlib 1.0"
(file "/opt/local/bin/port" line 40)

So, I tried sudo port selfupdate and ran into the same problem. Whatever port command I tried I got the same response, clearly I needed to take some sort of action. After a quick look at the MacPorts website I figured I should update my Xcode Tools to the Snow Leopard version, so I did that, (there’s an installer in the Optional Installs folder on the Snow Leopard disk) and tried sudo port list installed again, and got the same response as before.

Some quick Googling & reading resulted in no quick answer, so I figured that since I don’t really have anything irreplaceable in my MySQL databases I would download the Snow Leopard DMG from the MacPorts download page, install, and see what happened. That’s the solution! Just download the Snow Leopard DMG and re-install. All of your ports will still be there, and mine seem to be working so far.