Next week, we’ll be releasing v2.1.2 of SuperDuper with various improvements, including Growl support. I think you’re all going to like it.
We’d been investigating various methods of notifying users of successful and failed copies for some time, especially for users who are backing up headless or remote systems, and decided to leverage Growl’s well-tested and mature functionality rather than roll our own. It’s a nice package, and I’m glad it’s out there.
There’s a ton of flexibility built into Growl: you can show status visually with various types of floating panels and pop-ups, mail to any account, and even forward notifications to other machines on your network.
Putting this into SuperDuper! initially seemed pretty easy, but we ran into some unusual problems with our AppleScript-based “schedule driver” that I thought might prove interesting.
Obviously, we couldn’t require Growl—a 3rd party application—to be present on a user’s system. The idea here is to use Growl if present, not mandate it. But, our schedule driver—which can be extended by the user—is compiled “on-the-fly” when a schedule is created or modified.
But, while AppleScript has various techniques for dealing with a missing application or dictionary when running a compiled script, it really, really, really wants it to be present during compilation. So, a statement like
tell application “GrowlHelperApp”
notify with name “Scheduled Copy Succeeded” title “SuperDuper! Copy Succeeded” description “Copy was successful.” application name “SuperDuper!”
end tell
won’t work if GrowlHelperApp isn’t present on the User’s System. Drat.
AppleScript does, however, have something called “raw event syntax”. Basically, you pre-compile your statement, hand-compiling it into Apple Events. Thus:
tell application “GrowlHelperApp”
«event notifygr» given «class name»:"Scheduled Copy Succeeded”, «class titl»:"SuperDuper! Copy Succeeded”, «class desc»:"Copy was successful.”, «class appl»:"SuperDuper!"
end tell
But, this won’t work either: even though there’s nothing in the tell block that needs the dictionary, the tell itself will try to reference GrowlHelperApp, and fail. And if GrowlHelperApp is there, your AppleEvents will be magically transformed into AppleScript when you compile!
So, there’s no choice here—you have to have a tell block, or the events don’t go to the right application. But you can’t “tell” an application and have the compilation succeed if the user doesn’t have Growl installed! Or can you…
Fortunately, a little evil goes a long way in AppleScript. By using a string variable, rather than a string literal, we can prevent the compiler from loading the dictionary at compile time—and since we’re using raw event syntax, there’s no error. Thus:
set growlAppName to “GrowlHelperApp”
tell application growlAppName
«event notifygr» given «class name»:"Scheduled Copy Succeeded”, «class titl»:"SuperDuper! Copy Succeeded”, «class desc»:"Copy was successful.”, «class appl»:"SuperDuper!”
end tell
Bingo! This actually allowed compilation… and worked fine when tested in a simple script. But, in the real one, it didn’t work. Instead, I got the following runtime error:
Finder got an error: application “GrowlHelperApp” doesn’t understand the «event notifygr» message.
Now, of course, it does understand the message, because it worked in the simple case!
It took a while for me to figure it out, but the difference, was that in the real script, the Growl notification was in a nested tell block. And, even though the “nearest tell” is for GrowlHelperApp, for some reason this was seen as Finder’s GrowlHelperApp, rather than mine. (You’d think they’d be the same, but not so much.)
The solution, after much gnashing of teeth, was to explicitly reference the script’s main execution context, with:
set growlAppName to “GrowlHelperApp”
tell my application growlAppName
«event notifygr» given «class name»:"Scheduled Copy Succeeded”, «class titl»:"SuperDuper! Copy Succeeded”, «class desc»:"Copy was successful.”, «class appl»:"SuperDuper!”
end tell
I’m telling you, AppleScript has the unique ability to make me feel like the stupidest developer on the face of the earth. Kudos to you, AppleScript!
Anyway, expect this early this week…
James Wiebe, of WiebeTech, has written a terrific white paper that exhaustively analyzes the reliability of external enclosures, detailing the factors that contribute to failures.
As we’ve known for some time here at Shirt Pocket, large capacity external drives that use multiple physical drives in a single enclosure to boost their performance and capacity are much less reliable than single drive units.
As far as I’m concerned, anyone who relies upon hard drives for storage, backup or otherwise, should read and understand this paper.
Thanks for writing it, James!
Despite being down and mostly out with a cold/flu, I’ll be appearing on The Tech Night Owl LIVE tonight, May 4th, talking about SuperDuper!, netTunes, launchTunes, and desperately trying to not cough up a chunk of lung.
You can tune into the broadcast from 6:00 to 8:00 PM Pacific, 9:00 to 11:00 PM Eastern, at http://www.techbroadcasting.com. An archive of the show will be available for downloading and listening within four hours after the original broadcast.
You can also access the show’s Podcast feed, available at: http://www.techbroadcasting.com/nightowl.xml.
Trying to set a record for number of posts in a day or two here at Shirt Pocket Watch… some more praise today, and a five-star review (w00t!) from the fine folks at Macworld:
Whether you use it to make one-off clones for IT work or to make scheduled, bootable copies of your Mac’s hard drive for backup purposes, SuperDuper is the best clone-based backup utility I’ve seen—and the backup utility to which I trust my own data. Its clear interface, outstanding feature set, informative documentation, and—most importantly—fail-safe performance have made it an indispensable part of my Mac toolbox.
Dan Frakes writing in Mac Gems. Thanks, Dan!
Maurits, of plasticsfuture, has posted an exhaustive, two part review of backup programs on Mac OS X. The first part focuses on the general issue of backing up files on OSX, and the second contains an extensive analysis of more backup programs than I’ve seen covered in one place—freeware, shareware and commercial.
In my blog, I tend to talk about the usability aspects of SuperDuper!, because that’s where I focus my efforts. I can only do that because Bruce and I have very high standards for the rest of SuperDuper!, and Bruce’s copy engine is second to none. In fact, in this review of 16 tools, SuperDuper! was the only tool that worked correctly:
The surprising conclusion is that almost all Macintosh backup or cloning programs do not fulfil (sic) their primary purpose, i.e., they are not able to restore files with all associated metadata. This is despite the fact that many of the tools are advertised as “safe”, “accurate”, “bug-free”, etc. The tools that fail are harmful because they generate a false sense of security. Even more exasperating is that many of these tools cost (significant amounts of) money. The only laudable exception is the great SuperDuper application, which performs flawlessly. (Emphasis mine.)
Many thanks to the pseudonymous Maurits for putting this whole thing together: it couldn’t have been easy to do.
Today, I spent some time testing out the soon to be released update to netTunes along with Salling Clicker’s “Clicker Network”. My setup here is different that most, no doubt, but here’s what was involved:
- Music server running iTunes
- Various AirPorts running a WDS network bridging all over the house
- My main PowerMac, which I’m logged into, running the netTunes client, controlling my Mac mini, which is connected to my stereo
- iChat, set to show my current track
- My phone, running the Clicker Client, connected via Bluetooth to the PowerMac, but bridged over Clicker network to the Mac mini
- The Mac mini, which has no local music, using shared playlists to connect back to the music server
- Two Intel Macs connecting to the Mac mini’s netTunes server
- And, finally, the netTunes server, running on the Mac mini
OK, so—sitting in front of my PowerMac, I could see what I was playing on the Mac mini, because netTunes was showing me the iTunes running over there. And I could control it from that or the two Intel Macs also viewing the same thing.
Clicker—even though it was connected to my PowerMac, was showing me what was playing on the Mac mini, since it was using Clicker Network… and it updated properly when I made changes with netTunes.
My iChat status was showing the track I was playing on the mini, even though I was on the PowerMac, because netTunes is smart enough to act like iTunes and send out the proper notifications to make that happen.
And—no matter what I used to interact with the music—Clicker, netTunes, whatever—everything just worked exactly the way you’d expect.
I’m telling you, my smug sense of self-satisfaction was probably detectable from space.
I just wanted to give a bit of a Heads-Up to Teh Internets Users who might be relying on the Restore tab of the DVD that came with their Intel Mac.
Unfortunately, the copy of Disk Utility that’s on those DVDs (I’ve checked the one for the MacBook Pro and the iMac, but I don’t have an Intel Mac mini to test with) has a non-functioning Restore tab: the tab relies on drag-and-drop to set the destination volume (if you’re not using an image, the source as well), and—due to what looks to be a bug in this specific version of the utility—drag and drop does not work in the volume sidebar.
This means it’s not possible to restore a volume when booted from this DVD (regardless of how that volume was created). If you’re relying on the DVD’s restore functionality, I suggest installing a minimal system to a small partition on an external drive instead, as the Disk Utility that’s part of Tiger itself works just fine.
