Next post Previous post

Not dead yet

February 19, 2014 at 8:52 PM by Dr. Drang

This is a followup to my Mavericks Mail post of a couple of days ago. I think I have a better understanding of one of the problems I was having and a workaround for the other.

I can hear many of you saying “Just drop Mail already. It isn’t worth the effort.” You’re probably right, but I’m not in a position right now to switch. Because of the nature of my work, I have a hybrid system in which some of my mail is saved in local mailboxes and some is saved in IMAP mailboxes. Before I move to another mail client, I have to be sure I can export/import all of that structure without losing anything. Maybe that’ll be easy, maybe it won’t, but to be on the safe side, I don’t want to start the migration until my work schedule is a little more open than it is right now.

There’s also the issue of which client to switch to. I mentioned MailMate in the earlier post, but several friends on Twitter have recommended Airmail. And I should probably look into Postbox, too. Whichever I choose, it isn’t going to be a drop-in replacement for Mail. And wouldn’t it be wonderful if Apple fixed Mail and made it so I don’t have to decide?

As for the problems I’ve been having with Mail, let’s start with an update on searching. Many of you suggested that the problem was with Spotlight and that a reindex of its database might be a solution. I think that’s exactly right, and I kind of thought that running the Mailbox‣Rebuild command (which I mentioned in the update at the bottom of the post) would do just that. Apparently not, although it may have started the reindexing process.

After posting the update Monday morning, my disk chitter-chattered for about an hour. Activity Monitor told me one of the md* processes was running all that time, not taking up much CPU time, but definitely exercising the read/write heads. As best I can tell, searching in Mail has worked correctly since then.

I’m willing to accept a fair amount of the blame for this. The clearly incorrect search results I was getting should have prompted me to think of Spotlight. I have only two things to say in my defense:

  1. I almost never use Spotlight proper, by which I mean the thing in the menubar. If I use it more than ten times a year, I’d be greatly surprised. I’m more comfortable using grep and ack to search for words in text files, and my world is almost entirely text files. So Spotlight just isn’t something that comes to mind, and I haven’t had enough experience with it to immediately recognize the signs when it’s gone flaky.
  2. Apple seemingly provides no automatic Spotlight diagnosis. If you don’t know your search results are incomplete, what would inspire you to reindex your drive? Why don’t Apple’s set of system launchd processes keep Spotlight in tune or a least warn you when it’s out of whack?

Speaking of launchd, I have a workaround for Mail’s no send/no receive problem. It starts with this AppleScript, which runs the two menu commands Apple recommends:

applescript:
 1:  tell application "System Events"
 2:    tell process "Mail"
 3:      tell menu bar 1
 4:        tell menu bar item "Mailbox"
 5:          tell menu "Mailbox"
 6:            click menu item "Take All Accounts Offline"
 7:            delay 2
 8:            click menu item "Get New Mail"
 9:            --say "reset"
10:          end tell
11:        end tell
12:      end tell
13:    end tell
14:  end tell

The two-second delay in Line 7 came after some experimentation—with no delay, the “Get New Mail” command wouldn’t work.

The AppleScript is named Reset Mail.scpt, and it’s stored in ~/Library/Scripts/Applications/Mail which makes it available to FastScripts if I want to run it manually.

Mostly, though, I want it to be run periodically by launchd. So I created this launch agent plist file,

xml:
 1:  <?xml version="1.0" encoding="UTF-8"?>
 2:  <!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
 3:  <plist version="1.0">
 4:  <dict>
 5:    <key>Disabled</key>
 6:    <false/>
 7:    <key>Label</key>
 8:    <string>com.leancrew.ResetMail</string>
 9:    <key>ProgramArguments</key>
10:    <array>
11:      <string>/usr/bin/osascript</string>
12:      <string>/Users/drang/Library/Scripts/Applications/Mail/Reset Mail.scpt</string>
13:    </array>
14:    <key>StartInterval</key>
15:    <integer>600</integer>
16:  </dict>
17:  </plist>

named it com.leancrew.ResetMail.plist, and saved it in ~/Library/LaunchAgents. Items in that folder are supposed to get loaded into launchd when you log in. You can also force an agent to load and start with these commands from the Terminal:

launchctl load ~/Library/LaunchAgents/com.leancrew.ResetMail.plist
launchctl start com.leancrew.ResetMail

The best quick introduction to launchctl—all killer, no filler—is this post by Nathan Grigg. I return to it every time I need a refresher, which is basically every time I need to use launchctl.

A few words on these files:

Whenever I get around to switching mail clients, I’ll have to remember to tell launchd to stop running the script. This will stop it immediately:

launchctl stop com.leancrew.ResetMail
launchctl unload ~/Library/LaunchAgents/com.leancrew.RestMail.plist

I think I can leave the plist file where it is if I change the Disabled setting in Line 6 from <false/> to <true/>, or maybe I’ll have to use the -w option with launchctl unload. Most likely, though, I’ll just move the file out of the LaunchAgents folder so there’s no chance of it loading the next time I log in.

Next post Previous post