Use Dropbox to sync MarsEdit across multiple machines

As great as MarsEdit is (and it is great), it doesn’t yet let me sync drafts across multiple machines. With respect to WordPress (and some other CMSs), MarsEdit does allow you to save your posts as drafts on your web server; however, I have a general aversion to this because it requires that I remember to update the timestamp of the post (to the current date/time) when I actually publish it, and also causes the post IDs to stray from date-order (I know, I’m anal).

A couple of months ago a friend mentioned Dropbox (currently in private beta) in passing, and immediately I wondered if I could use such a service to do what I needed with respect to MarsEdit (and OmniFocus; see below). Turns out I could.

MarsEdit

To get Dropbox to play nice with MarsEdit you have to use symbolic links (because, as far as I know, MarsEdit doesn’t let you specify where you want to store your drafts and other data), and Dropbox will sync only what you drop into the Dropbox folder. The trick to using symbolic links in this scenario is two-fold: 1) you must make sure your usernames on each machine are the same; and 2) you must time correctly the creation of the symlinks on each machine.

Usernames

Regarding the first point, it must be understood that when you use the “ln” command to create a link, it resolves the tilde so that the path to the linked-to file contains your username (i.e., ~/Dropbox → /path/to/username/Dropbox). In light of this, the usernames on every “syncing” machine must match up, else the last machine to talk to the Dropbox folder will overwrite the symlink to point to the username on its machine; this obviously will break the symlink on the other machine because it will then point to a path that does not exist on that machine.

Dueling symlinks

Even if each instance of MarsEdit is being run under the same username, you still may run into some problems (but these can be remedied; keep reading). When I first set out to get sync working, I saw some funky behavior. For example, I’d create the symlink on machine one, run a couple of tests on machine one to make sure it was working, and then run some tests on machine two (which immediately showed the symlink in its Dropbox folder, as it should).

At some point during this process, the symlink on machine one would break, and the LocalDrafts folder (the MarsEdit folder I was trying to sync) would be copied into the Dropbox folder and the symlink removed entirely. You can appreciate the problem: both machines were now synced, but MarsEdit could no longer see the synced folder because it existed outside of the hard-coded directory used by the application.

To get around this, I thought to create the symlinks on both machines semi-simultaneously, in the hope that some contention rule would let them stand on their own (i.e., machine one wouldn’t ‘cause’ the symlink to be created on machine two, and therefore wouldn’t set into motion the problem just described).

Well, my hunch was correct — creating the symlinks at the same time does the trick. Over the last couple of months I’ve had zero problems with the setup; the symlinks on both machines have persisted without issue.

Finally, the actual solution

Remember that Dropbox syncs only what’s in its folder, and so the symbolic link must be placed there. To do this, simply navigate, on every machine you want synced, to ~/Dropbox/, and execute the following command (simultaneously on all machines):

ln -s ~/Library/Application Support/MarsEdit/LocalDrafts marsdrafts

That’s it. Realize that “marsdrafts” is the new directory entry that will be created; you can name this whatever you want. Keep in mind that if you have MarsEdit open on two machines simultaneously, and make changes to a draft on machine one, those changes may not show up on machine two until you restart MarsEdit on machine two (which will cause the application to re-read the LocalDrafts folder).

OmniFocus

OmniFocus lets you specify where you want to store your database file, and so it’s trivial to get it working with Dropbox (i.e., simply tell OmniFocus to store the database file in the Dropbox folder).

However, there is one caveat. You’re going to want to quit OmniFocus on machine one before firing it up on machine two, else you’ll likely run into the file being locked by one instance of the application, which can result in some weird (and maybe fatal?) contention issues.

I note that this method, and the issues that come with it, have been obviated by the sync-capable OmniFocus v1.1 (currently in pre-release). While on the topic, and despite my grumblings about the price, OmniFocus for the iPhone is very nice.

Other applications

These methods obviously may work with any other application you’d like to sync across multiple machines. However, you should remain cognizant that certain applications may have read/write mechanisms that preclude these particular approaches; as ever, backup your data before experimenting.

Wall·E

It’s no secret that I have a somewhat anti-utopian (as opposed to dystopian) view of the future (and present!) of mankind (“Oh, hello there AI. Please don’t kill me!”), and on the whole, generally prefer my movies sad, and my music sadder. To that end, the first half of Wall·E really delivered.

How could you not be moved by the drab, post-human, almost post-robot Earth? Talk about being simultaneously harrowing and beautiful: the melancholic color palette, the dutiful robot carrying on with its “directives” even though there is no one left on Earth to appease, the non-dialogue, the re-packaging of consumer detritus — man’s legacy — into skyscrapers, the “non-junk” saved and savored by Wall·E, and his painful-to-watch attempt at piecing together the human condition and connecting with the past that built him.

You kind of forget that Wall·E is a robot, much less a cartoon robot. Brilliant.

Ah, a perfect beginning to what could have a been a near-perfect movie, but which eventually transmogrified into something else entirely, something packaged and predictable, something happy.

I get it — everything has to work out in the end. For the kids. But, it all felt a bit manufactured and forced to me, and ultimately the ending completely belied the beginning. Or, by the grace of some cosmic, ironic redemption, the whole thing came full circle. Who knows.

Pixar’s ability to consistently deliver movies — over and over and over again — that appeal to every age, is something that puts it in an untouchable class of its own; at the same time though, that versatility continually demands it sacrifice honesty for marketability, and (especially in Wall·E) vision for profit.

There is no doubt that the pre-watch hype surrounding this movie (“OMG! Greatest movie ever!!!”) had a role in it not living up to my admittedly impossible expectations, but such influences notwithstanding, I still came away from it slightly underwhelmed. Don’t get me wrong, I enjoyed the majority of it, but something definitely was missing.

It’s a smart, emotional movie, and I will no doubt watch it again many times over; I just wish the second half was a bit more like the first, the messages not so strained, and the ending slightly less optimistic.

If I’m being completely honest, I found the similarities to Johnny 5 a teensy bit grating. After all, I’m a robot-loving child of the ’80s (and, if memory serves, had the movie on both VHS and Beta) — how am I supposed to feel?  ;)

MS Exchange email drafts on the iPhone

The iPhone’s built-in support for MS Exchange is great, and has worked for me without issue since setting it up yesterday. That said, there is one niggling nut I’d like to crack, if possible.

Let me start by saying that I’m pretty sure the problem isn’t on Apple’s end; I think it’s just how Exchange handles the situation, though I have no real experience with Exchange and can’t say for sure (please correct me if you know).

The issue is that when I save drafts of emails on a computer other than the iPhone, those drafts, while “available” on the iPhone, act like emails I’ve received (though they are devoid of sender information); given that copy/paste is still a pipe dream on the iPhone, the drafts are effectively useless (i.e., I can’t send them!).

There is a similar issue going the other way as well; that is, when I create a new email on the iPhone, and save it as a draft, that draft never appears on any of my other Exchange-aware machines. On the iPhone, a new “drafts” folder appears in the folder list (for those counting, there are now two folders named “drafts”), but I don’t think that folder talks to Exchange (i.e., it’s the local-only drafts mechanism built into the iPhone Mail app).

So, the question is this: how can I get the iPhone Mail app to treat Exchange-created drafts as drafts?

Weave v0.2 and tab synchronization

A couple of weeks ago I published a piece regarding the death of Google Browser Sync, and its heir presumptive, Weave, which at the time, did not yet support the feature I care most about, namely session restoration across multiple machines. Not long after pushing that piece into the ether, a few people emailed me to let me know that a tab-syncing version of Weave would be released on June 20th; though the release date slipped a bit, v0.2 was made available a few days ago, tab synchronization intact. Well, kind of.

Since the release, I’ve been testing the tab-syncing functionality, and unfortunately, I have to say it hasn’t worked too well. There have been times when it has presented to me tabs from machine one that weren’t currently open on machine two, but this behavior — the intended behavior — is sporadic at best.

The following is my attempt to sum up what I’ve experienced over the last couple of days (please forgive me the bullets), after which I’ll describe what I think is wrong with the implementation (even assuming it worked perfectly).

• When I quit Firefox, the browser window(s) falls away and a small “Syncing with Weave…” window appears. This never finishes; in fact, I’m not sure it transfers anything to, or receives anything from the server. I inevitably have to kill the Firefox process.
• It seems that every other time I’m made to kill the Firefox process, Weave, upon a relaunch of the browser, has forgotten who the hell I am and I’m required to run through the entire “initial synchronization” process again.
• After the first click, clicking on the indicator that tells me there are “unsynced” tabs generally shows me nothing but a completely blank window.
• Of all the tabs I’ve had open, Weave seems to get confused by Gmail and Google Reader; it never thinks they’re synced up, and consequently never stops presenting them to me as “new” (on both machines). I’m assuming this has something to do with their shifting titles/URIs.
• Syncing sometimes takes forever and frequently stalls. Perhaps this can be attributed to the WebDAV server that we are all currently required to use (eventually, we’ll be able to sync to a WebDAV server of our choice).
• There seems to be some delay between when a new tab is opened and when it is actually synced. For example, if I open a new tab on machine one, manually sync machine one, and then manually sync machine two, machine two will not immediately show me the new tab. It may see it eventually, but it is by no means instantaneous.

I haven’t yet had occasion to pore over Weave’s activity log (I will this weekend), but I suspect it might shed some light on at least some of the issues I’ve encountered.

Implementation (and how it should be changed)

It’s called tab synchronization, which, in my mind, means it should be as automated as possible. As it stands, users have to consciously look for, of all things, a yellow triangle with an exclamation point in the middle. Yeah, a hazard symbol. Huh?

Assuming you notice this little “warning” in your status bar, you then have to click on it, which will [hopefully] present to you the tabs on your other machine(s) which aren’t currently open on the machine from which you’re clicking. Finally, you have to read through a list of page titles and check a box next to those pages you want to open. What is worse, there is no way to select all of them at once, and presumably that’s exactly what you want to do (I mean, you’re syncing, right?).

In my opinion, tab synchronization should work like so:

1. Use the browser on machine one.
2. Use the browser on machine two.

That’s it. I should never have to think about synchronization. When I open/close a tab on machine one, machine two should open/close that tab in the next sync cycle. I don’t need to interact with those processes other than to set them in motion by using the browser.

To the Weave team

Thank you. Please don’t confuse my comments with inappreciation or some sense of entitlement. Quite the opposite — I know how hard this stuff is, and recognize the nascency of the project. At the end of the day, I just want to see this thing reach its potential, which, I realize, goes far, far beyond tab synchronization.