Target disk mode versus removable hard disk on the new MacBook

I've been thinking about the lack of FireWire — and the concomitant loss of target disk mode — on the new unibody MacBooks.

I've had many occasions where target disk mode has been a godsend and others when it has just been convenient. I was able to move files off our iBook G3 after its screen failed, and had recent case where I was able to perform data recovery on another system when I had nearly given up hope of getting anything back (thank you, GNU ddrescue). So, I was naturally concerned about not having FireWire around, simply because target disk mode is so useful.

I have come to the realization that the most important situations where I have used target disk mode were for backups or data recovery. For those situations, I just need the drive. The hard disk is more easily removable in the new MacBook (and in the MacBook Pro), so it can be taken out. Then, it can be attached to an external interface or installed in an enclosure, if needed.

While that may not be quite as convenient as target disk mode over FireWire, it's not bad. Consider me appeased, my initial disquiet calmed.

I suppose the other situations will have their workarounds, too. Some of those workarounds will likely be slower than transferring data over FireWire, but oh well.

Frankly, I'm really happy to have both FireWire and the removable hard drive in the MacBook Pro line.

Update your address book from Apple Address Book

I am continually coming across useful features in my account that I have previously overlooked. For example, I now know that I can import contacts into the account’s address book. As with many mail systems, this provides several benefits:

  • You can use your contacts to address messages (duh).
  • Your contacts’ e-mail addresses serve as a whitelist for junk mail filtering.

Since I enabled “aggressive” filtering on my Fastmail account, having that whitelist functionality is of interest to me.

The Fastmail developers have helpfully provided a way to upload multiple kinds of contact data, so I chose vCards. They were easy for me to obtain from Apple Address Book. Here’s the basic process I followed:

  1. Export existing contact cards to vCard format from Apple Address Book. You can save the vCards somewhere and delete them later; one trick I use is to save temporary data like this to /tmp so it’ll be deleted by the next time I reboot. Address Book will export multiple selected contacts to one vCard file, and Fastmail accepts this.
  2. Go to Options > Upload Addresses on the Options/Settings page in your account. (Half the fun with Fastmail is wading through their exceedingly busy user interface.)
  3. Click on the “Choose file” button next to the “Address book file” label.
  4. Select your exported vCard file in the open dialog and click “OK” to upload it.

Fastmail has done a reasonable job of matching imported vCards to existing contacts, as long as they were previously imported from a vCard. I had some duplicates for those people who I'd added manually through the Fastmail interface before importing their vCards. Fastmail does state they try to match up contacts to reduce duplicates during the import process, but I still needed to do a little cleanup — and, unfortunately, there is no “merge contact” feature I came across.

For what it’s worth, the import process is fast, but I probably brought in under 100 contacts total, so I wasn’t necessarily taxing it.

Not all of the vCard data seems to come through and be displayed in the Fastmail address book. That's okay for me; I have it elsewhere. In particular, I didn't see Web addresses beyond the first one show up. Other contact information, like e-mail addresses and phone numbers, seemed to display fine. (I haven’t done an export from FM to vCards to see about roundtrip fidelity yet.)

Once you have cards in your address book, you can update them later. If you’re going to bother importing them in the first place, you’re probably concerned about keeping them up to date. Since the Fastmail software does a decent job of avoiding duplicates (in my brief experience), this shouldn’t be hard to do.

The most difficult part is sorting out which cards have been changed over time. You could re-import all of your cards, certainly. Or, you could use Apple Address Book to help find the recent changes to your contacts — whether those changes were done in Address Book or synchronized via Sync Services (perhaps from Microsoft Entourage).

Here’s how:

  1. Create a Smart Group in Apple Address Book to show cards that have been updated in the last seven days. Pick a period of time that works for you; seven days works for me for the moment.
  2. Select the Smart Group.
  3. Select all of the cards which appear in the Smart Group.
  4. Export the selected cards to a vCard file.
  5. Import that vCard into Fastmail using the steps above. Your changes are now in your online address book.

While this is far more manual effort than I’d like, it’s not terrible. It’s something that I can envision doing every few months. I do most of my e-mail in a desktop application rather than on Fastmail’s Web site, so if my online address book there is a little out of date, it’s not a huge concern.

Drupal Administration Menu module streamlines admin tasks

I just installed the Drupal Administration Menu contributed module, and I really like it. When you are logged in and have administrative privileges, it provides a small menu bar with drop-down menus and submenus at the top of every page in your site. It provides quick access to every admin function I’ve needed, and really streamlines the process of making changes to the site.

Here’s a screen shot of what it looks like:

Drupal Administration Menu module screen shot

In that respect, I rank it up there with the Taxonomy Manager module, which also provides a major productivity boost.

Update: Apparently I’m not alone; Administration Menu is among the modules included with the Acquia Drupal distribution. I think that lends quite a bit of credibility to this module … if my own recommendation didn’t provide a tipping point for you.

Launchd run once and remove the job

There are cases where you may want to have Launchd run a job once, and then have that job removed so it doesn’t run again. This topic came up on the Launch-Dev mailing list not too long ago and some answers were provided. In particular, Quinn the Eskimo said:

“Alternatively, don’t unload the job. Once a job is loaded, it
doesn’t depend on the plist file, so removing the plist file out from
underneath launchd won’t cause you any problems. The job will
continue to exist in launchd (until the system restarts) but it won’t
get run against unless someone specifically invokes it.”

Conditionally import a Python module if it is available

I have been struggling with the issue of module availability in Python. While the “batteries included” nature of the standard library is great, there are occasionally times when I need to resort to a module that isn’t included with Python.

There are also times where I’m using modules whose status has changed. I expect that to happen more in the eventual transition to Python 2.6 and 3.0, because I’ve used modules that are being deprecated.

So I wondered how I could conditionally import a module if it was available, without stopping the flow of my scripts — and gracefully handle situations where it is missing. And here’s one basic answer: use a “try” block to catch the “ImportError” exception. For example, if I were concerned that DNSPython wasn’t going to be installed on my target system:

import dns.resolver # Import DNSPython
dnspython_available = True
except ImportError:
dnspython_available = False

The “except ImportError” clause could specify a different module to load, or other workarounds entirely. You could map the namespaces in the “try” bock so the rest of your script doesn’t notice the change in module functions, if you have a way to work around the missing module. Perhaps, you could even try to obtain and install the module, at least for temporary use by your script.

Thanks to authors of the article Python modules – how do they work? for the assist. The information under heading 2.11, “Is my module available?” answered my question and has given me something to think about.

Microsoft Entourage error -18576 as it happens

I have had a problem that has repeated since I first began using Entourage as an Exchange client since at least version 11.0. I’ve never been able to solve it, but let me at least explain it here, because I’ve seen other people encounter it as well. It’s error -18576, and I hate it.

The symptoms are that I have calendar events displayed locally in Entourage that do not appear to synchronize to an Exchange mailbox. The Exchange mailbox, or account, does have some but not all of my calendar events.

There doesn’t seem to be any rhyme or reason to events that are missing. Many of them are recurring entries on my calendar. Beyond that, I’ve had events I put on my calendar myself, events that have been created through invitations from others, events with and without categories assigned, events that were created manually or with AppleScript, events that are flagged private, and so on.

The sequence of events I see in a traffic capture for affected events goes something like this:

  1. Entourage tries to LOCK (a WebDAV call?) the event at a URL path ending in /exchange/userid/Calendar/eventname.eml.
  2. Exchange returns an “HTTP/1.1 401 Unauthorized, NTLMSSP_CHALLENGE” response.
  3. Entourage tries to LOCK the event again, at the same URL path.
  4. Exchange returns an “HTTP/1.1 201 Created” response.
  5. Entourage attempts an HTTP PUT of the event at the URL.
  6. Exchange returns an “HTTP/1.1 200 OK” response.
  7. Entourage attempts an HTTP PROPPATCH of the URL.
  8. Exchange returns a “HTTP/1.1 207 Multi-Status” response.
  9. Entourage attempts to UNLOCK the URL path.
  10. Exchange responds with “HTTP/1.1 424 Method Failure.”

That’s it, that’s the extent of the HTTP/WebDAV exchange between Entourage and the Exchange server. The Entourage Error Log shows an -18576 error, but as of Entourage 2008, has no further description. Entourage’s Exchange-related errors are numbered in the -18000s and are typically based on HTTP (see the Entourage Error Page; use the equation 19000 + error number to determine its HTTP equivalent.

In my case, this is an HTTP 424 error, or a “Failed Dependency.” According to RFC 4918 on WebDAV, this means “The property change could not be made because of another property change that failed.”

The end result in Entourage is an event that does not appear in the Exchange calendar, but does appear locally — and there’s that entry in the Entourage Error Log, of course. There’s one such for each attempt to sync an affected event, so they build up over time — but some events do synchronize. It’s more aggravating that I’m left with a feeling of being in limbo, not knowing whether any calendar I’m looking at is correct or not. (Is there a sniglet for that? Update: I hereby propose “calendremma.”)

It doesn’t seem to matter whether Entourage is connecting to a front end or back end Exchange server (at least through Exchange 2003). Rebuilding the Entourage database doesn’t clear up the problem, although seems to occasionally have offered some temporary respite. However, the events that didn’t sync before still don’t sync.

The events which don’t synchronize fail to appear via Exchange ActiveSync on my iPod touch, and aren’t visible in either Outlook Web Access or Outlook for Windows.

Search field keyboard shortcut in Mac OS X toolbars

I’ve long had a problem with the search fields that are omnipresent in the toolbars of so many Mac OS X applications. My problem? I wanted to quickly jump up to them so I could enter text directly, but I wanted to do so with a keyboard shortcut.

This is particularly true in Safari and Keychain Access, two applications where I frequently want to use the toolbar search field.

It turns out that I was too lazy to look for it, and the option is labeled in a misleading way. I’ll admit, I just plain missed the keyboard shortcut.

The command can be labeled as “Find” where I’ve seen it. It may vary and carry some additional text, as in Safari where it is “Google Search” and MarsEdit where the label is “Search Weblogs,” both of which make sense when the resulting action is to jump to the search field. In both of these applications, the command is in a submenu under Edit > Find.

In Keychain Access, it’s just “Find” — so it doesn’t even match the label on the “Search” field it sends cursor focus to.

The keyboard shortcut is Option-Command-F, and appears as ⌥⌘F.

It’s sad when you can’t find the “Find” command, isn’t it? Grin.

Per-podcast settings in iTunes 8

I’m really going to have to dive into one new feature in iTunes 8: last night, I discovered that it has per-podcast settings. I’m pretty sure the settings were only available globally before, and I didn’t see anyone else talking about this change yet.

These settings can override the defaults for:

  • how many episodes to download
  • how long to keep episodes.

This is tremendous, although unfortunately it will lessen the opportunity for third party tools like Cast Away. (However, I’ve found Cast Away extremely complex.)

Rethought zshrc

I’ve been using zsh for a while as my preferred shell. I have a hacked-together zshrc file, and yet really wanted to use it across multiple systems. Some of those systems are running Mac OS X, others Solaris, and still others Linux. Executables are in a different locations and even have different switches across this range of systems, so my cobbled zshrc was not helping me.

As I was about to fall asleep last night, it finally hit me that fixing my zshrc would be a good thing to do. I jotted down some notes about an idea to reorganize it, and did something about it today.

Of course, since I’ve checked my zshrc and other dotfiles into a Mercurial repository, I could experiment without fear.

I created three top-level functions, with one “case” statement in each. Case statements may be evil in some fashion, but they are one of the things I like about shell scripting. These statements do allow the script to make choices based on the host, operating system, or shell that it was running in. (Yeah, it’s a zshrc, but I sometimes do stupid things — like sourcing it in bash on the one Linux system that won’t let me switch to zsh. Site5, I’m looking at you.)

I separated all the important sections of my zshrc into their own individual function calls. Each of those function calls was placed into one of the applicable case statements.

The case statement functions figure out the conditions the zshrc is running in, and then run the other functions to set up my environment.

The changes tested well from first try across the various platforms and hosts I log in to. I did have a minor problem with the hostname command, because Solaris doesn’t have a “-s” flag for it. Eventually, I solved that — and the odd “uname: error in setting name: Not owner” error I got, even though I wasn’t directly running uname there — by replacing hostname with uname.

Thankfully, it works for me, and it should be a little easier to manage changes in the future.

Drupal 5.10 and MarsEdit

Now that I’ve upgraded to Drupal 5.10, I’ve discovered I can no longer post from MarsEdit. I get this error upon submitting a post via XML-RPC, via Drupal’s core Blog API module:

You either tried to edit somebody else’s blog or you don’t have permission to edit your own blog.

Annoying things like this happen all too often with Drupal. I’ve had enough problems with the core BlogAPI and (practically required) Pathauto modules that I should really consider whether the Drupal platform is worth it. It feels like updates for modules are never really tested before they are put out, and so problems like this slip through.

I haven’t figured out what the problem is yet, but hopefully I’ll get this fixed soon. I hate posting through Web interfaces if I can avoid it.

And, just to be clear, all I did was update to the current Drupal 5.10 via my normal routine. I kept my “settings.php” file and my “files” and “sites/all/modules” directories, but everything else is from Drupal 5.10. I ran the “update.php” script after the upgrade. No settings were changed in MarsEdit, which worked before the upgrade.

Update 9/20: I looked in the “Access control” page of my sites’ Drupal Administration section. The “administer content with blog api” had been turned off for my user role. I re-enabled it tentatively, and now posts from MarsEdit appear to work again. I’m not sure why the “administer content with blog api” permission would have been disabled in the Drupal 5.10 update, but that’s what appeared to happen to me.

Syndicate content