John Topley’s Weblog

One of the toughest tests of an operating system is how well it copes when disaster strikes and you have to somehow get your data back. Last weekend I found myself in this situation for the first time since I switched to using Mac OS X. I thought it worth recording the experience here simply for the selfish reason of having a note of what I did should the situation arise again.

The troubles started when I ran Apple’s Software Update application to upgrade my iMac to version 10.4.11 of Mac OS X Tiger. I foolishly assumed that this would be a no brainer since I’d already taken the big step of doing a clean install of Mac OS X 10.5 Leopard on my PowerBook. Incidentally, I’m conservatively holding off installing Leopard on the iMac until a Leopard-compatible version of the SuperDuper! system recovery software is available. Expect some views from me on Leopard once I’ve had a bit longer to live with it.

Unfortunately Software Update chose an operating system update as the moment to go wrong for me for the first time. Up until this point I’d never had the slightest whiff of trouble from it. It ran most of the update and then told me that it couldn’t complete and had put the installer package in the Trash. I did think that this was quite amusing, as if my Mac was telling me that the update I’d downloaded was rubbish and deserved to be filed accordingly! I retrieved the installer and ran it as a standalone update and got the same error. I think I rebooted at this point and was surprised to see that I did in fact appear to be running 10.4.11, complete with Safari 3.0 and its draggable tabs. I checked in the Software Update log but there was no mention of the update, so I guessed that it had merely crashed before it had chance to write to the log and do a general tidy up that left my operating system looking presentable and ready for use again.

Next I noticed that the rather important mach_kernel file was visible in the Finder in the root of my system disk. After a Google search I fixed that by doing:

sudo /Developer/Tools/SetFile -a V /mach_kernel

—And restarting the Finder. All appeared to be well until I plugged in my iPod and nothing happened apart from it starting charging. I knew that it needed charging so I wondered whether it simply didn’t have enough juice to sync. Unfortunately I was wrong and there then followed several resets and the forcing of FireWire Transfer Mode, all of which were to no avail. By now I was starting to get worried. At this point in the story I must admit that I did entertain guilty thoughts about how this could be a sign that I should replace my faithful but aging fourth generation iPod with a brand new iPod touch, but with a great effort of will I banished such thoughts. Beware the Reality Distortion Field!

As I couldn’t get the iPod to do anything I came to the conclusion that the only path open to me was to roll back my Mac to its last known good state, so I powered up my external hard disk and was somewhat alarmed to find that it wouldn’t mount. That was when I launched System Profiler and discovered that according to my Mac it didn’t have a FireWire bus. *#^% indeed!

The situation was getting quite serious now so I needed a plan. Fortunately I had two things on my side. Firstly, I had on my external hard disk a complete SuperDuper! copy of my iMac’s working 10.4.10 installation from only a few days before. The second thing I had going for me was that I had a Mac, which makes it really easy to start up from other disks or generally shuffle the entire OS about.

I swapped the connection to the external drive from FireWire to USB and booted from my Tiger install DVD. Next I fired up Disk Utility and dragged the external drive icon to the source field and the icon for my system disk to the destination field. I clicked the Restore button and waited rather a long time as over 120 GB was copied across. There was one heart-stopping moment as I got an obscure error code right at the very end of the restore process. There was nothing to lose by now so I ejected the DVD and rebooted. My iMac took longer than usual to start but it did come back up and I logged in and to my absolute joy found that I was back to using 10.4.10.

However, it wasn’t all plain sailing as I discovered when I started Safari. Although it was back to Safari 2.0, all of my bookmarks were missing and the Import Bookmarks menu item was permanently disabled. I’d had enough by now, so I decided to run Software Update to get 10.4.11 again, with a vow that if that didn’t work then I’d wipe the disk and install Leopard from scratch. Happily, Software Update worked perfectly this time and the upgrade to Safari magically restored all my bookmarks.

My iMac was now back to rude health apart from a niggling little problem of some UNIX-y folders such as /etc, /var and /tmp being visible in the Finder. Perhaps they should have been made invisible right at the end of the restore process when it crashed. I was able to resolve that issue with another Google search followed by entering the next line into a Terminal window:

defaults write com.apple.Finder AppleShowAllFiles NO

—Relaunch the Finder by Option-right-clicking on its Dock icon and the job’s a good ‘un.

Overall I’d have to rate the Mac disaster recovery experience as being on a par with the rest of the Mac experience i.e. generally well thought-out and pretty painless. Certainly I’d say that SuperDuper! is a must.

Incidentally, the hairiest disaster recovery experience I ever had was a few years ago when my installation of Windows 2000 went badly wrong and wouldn’t let me log on, because the driver letters had got mixed up. I fixed that one by installing a parallel copy of Windows 2000 and then using regedt32.exe to load the registry of the broken installation. I was then able to edit the GUIDs that Windows uses internally to represent drives and partitions. At the time it felt like the task required a similar level of concentration and calm that you would imagine for dismantling a bomb! Fortunately I didn’t break into a sweat this time around.

Emergency Button photo credit: Matt Davis.

I went to a great gig in London last Friday with my good buddy John Conners. In a bizarre twist on the traditional format for these things, it was actually a presentation on project management software for software teams, rather than a music gig. If you think that sounds boring, then you’d be right. Fortunately, the person giving the presentation was none other than A-list celebrity software blogger Joel Spolsky of Joel on Software fame. Joel and Fog Creek Software co-founder Michael Pryor were in town to promote the latest version (6.0) of FogBugz, which increasingly embodies Joel’s philosophies on different aspects of the software development process.

The venue was the conference centre at the British Library, which was jam-packed with geeks—mainly male, it has to be said. Joel gave his presentation which included a FogBugz demo, then the floor was opened to questions and finally Joel and Michael stuck around afterwards to answer questions on a more informal basis from the throngs of developers that surrounded them.

The most interesting new feature in FogBugz 6.0 is Evidence Based Scheduling (EBS). Joel himself would probably characterise it as a hand-wavy sounding feature, but from watching his demonstration it actually looks practical and useful. What it boils down to is this: FogBugz makes it as painless as possible for developers to record what they’re working on and then over time it uses statistical modelling techniques to generate fancy charts that tell you a percentage probably of when your team will ship, or how accurate individual developers have been at estimating their work. Joel blogged about the feature in depth a while ago.

FogBugz 6.0 also includes a handy wiki feature that serves as a central project documentation repository. What’s interesting to me about how they’ve implemented this is that it only has a WYSIWYG editing mode i.e. you can’t get at the markup that’s generated under the covers. I suspect that Fog Creek have learned from their experience with CityDesk here, which had all sorts of problems when you switched back and forth between the editor view and the markup view. Joel actually touched on this during the Q & A when someone asked if WYSIWYG is a leaky abstraction: the short answer is that it is.

What I found most useful from a FogBugz point of view was getting a leg-up on how to use the software effectively. I’ve been using the hosted version for a while for AssetsGraphed, but I knew that I wasn’t getting the most out of it. I had trouble coming to terms with the FogBugz model whereby everything is essentially a case within the system, even e-mail. That’s all a lot clearer now and I shall shortly be hooking up the AssetsGraphed contact screen to FogBugz, so that any feedback I receive from users is properly categorised and managed. After that I’ll hook up the crash reporting system, which means that new cases will get created automatically on those rare occasions when the application crashes, instead of the present system which simply e-mails me the details. The beauty of it being that FogBugz is smart enough to recognise when incoming crash details are the same as previous crash details and so won’t create lots of duplicate cases, but rather will append to an existing case.

I’ve also developed an appreciation of what a sophisticated AJAX application FogBugz now is! I think this is something of a well-kept secret because FogBugz doesn’t advertise its use of AJAX in a flashy way, it just makes the experience of using the software faster and more pleasant. One feature that I certainly was aware of from the previous version is the great keyboard support, which is far superior to any other web application I’ve seen. Just as one thing Microsoft got right with Windows from the start was the ability to drive the user interface using only a keyboard, you can get around FogBugz in the same manner.

Joel turned out to be exactly how I expected, which is to say an entertaining and interesting speaker who answered everyone’s questions with patience and charm. Talking of questions, I was a bit surprised that some people used the occasion to glean information that can be easily found on Fog Creek’s website. I guess there were quite a few people there who wanted to find out about FogBugz straight from the source rather than attending because they’re JoS fans. We certainly did find out all about the latest version of FogBugz and very impressive it is too. My only slight disappointment with the event was that there was no FogBugz World Tour 2007 merchandise for sale, such as T-shirts with a list of tour dates on the back. Not very rock ‘n’ roll, Joel!