Ending Endless Time Machine Backups

I've been having a serious problem with, of all things, my Time Machine backups, which is a huge problem as my computer dies a slow, painful death and I wait for the imminent MacBook Pro hardware release. Since replacing my internal hard drive, Time Machine had seemingly decided to perform only full backups. For me, a full backup is a few hundred gigs, so every backup was taking several hours to perform. 

There is a terrific website that details nearly every problem you can have with Time Machine, as well as solutions for these problems. It's official title is Apple OS X and Time Machine Tips, but everyone just calls it pondini.org. It is the resource for your Time Machine troubles.

I tried pretty much every fix listed on that site and nothing worked.

After watching Time Machine roll over for the umpteenth time, however, I began to notice a pattern. For one, each time the backup began anew, the amount of data to back up was the same. In addition to this, it was not the full amount of my combined multi-volume backup. After poking about a bit with the ever handy tmutil command, I began to suspect that the trouble might lie not with Time Machine itself, but rather with one of the data volumes I was attempting to back up. 

So I started looking at my Work volume. This is the big ATA drive that holds the bulk of my data, while my system resides on a separate SSD. The Work volume was also the one that had recently died and been backed up. One thing I noticed about it was that it appeared to have ACLs and Extended Attributes on it. More importantly, some of those Extended Attributes appeared to be specific to Time Machine.

computername:~ username$ xattr /Volumes/Work/ com.apple.FinderInfo com.apple.backupd.SnapshotVolumeFSEventStoreUUID com.apple.backupd.SnapshotVolumeLastFSEventID com.apple.backupd.SnapshotVolumeUUID com.apple.backupd.VolumeBytesUsed com.apple.backupd.VolumeIsCaseSensitive com.apple.metadata:_kTimeMachineNewestSnapshot com.apple.metadata:_kTimeMachineOldestSnapshot

So I decided to turn off ACLs and also to remove the Extended Attributes.

computername:~ username$ sudo chmod -RN /Volumes/Work
computername:~ username$ for attr in `xattr /Volumes/Work`; do sudo xattr -d $attr /Volumes/Work; done

I also found a terrific web page that described the exact same problem I was having, and how they fixed it using this exact same method. That site filled in a few blanks for me, namely how to remove the Extended Attributes.  So thanks to expat.dyndns.org for the clear, well written article.

Since removing the Extended Attributes and ACLs from my Work volume, backups have been working properly — which is to say incrementally — once again.  

My computer is still dying. But at least when it does I'll have a current backup. 

 

Vesper Use-Case

When i first read about Vesper, the note-taking iPhone app by John Gruber, Brent Simmons and Dave Wiskus, I rankled a bit. Really? Another note-taking app? For five bucks? And no sync? 

But let's face it: I like Gruber — I like his website, I like his writing, and I like what he has to say about how digital tools work. Five clams for a notes app with no sync was almost a non-starter, but my curiosity got the best of me. If nothing else, I could test this thing out, see what all the hype was about, all the while supporting, in some small way, a guy whose site I've been reading for years. 

I've used iOS's Notes app for the bulk of my mobile note-taking, and it's mostly been great. But there's one area where I've needed some help. See, I make this webcomic called Malcontent. And I keep all my ideas for Malcontent — and, believe me, there are a ton of them — in one giant note. And, if I may be colorfully frank, this well and truly sucks major ass.

So I decided to dedicate my experiment with Vesper to this particular problem. I decided to take each and every Malcontent idea (did I mention there are a ton of them?) and transfer each to an individual, tagged note in Vesper. This is all I use Vesper for. It is my dedicated Malcontent comic idea app. And you know what? it works beautifully.

For one, Vesper is very easy to use. I can get a note down and properly tagged very quickly and intuitively. Compare to the olden days, using Notes.app, in which I'd have to scroll to the bottom of the über note, write the note, and then, without the joy of tags, promptly forget all about it until the next time I spent an hour going through the entire über note. Note taking is now far easier.

It's much more functional as well. Because now, with tags, I can find stuff really easily. I have a few basic categories that make doing this a breeze, and these are all easily accessed in Vesper's sidebar. 

Also, once I've used a comic idea, I can archive it without throwing it out. Doing this means I no longer have to look at it, but I still have it in the archive, which pleases to no end the completist in me (or maybe the pack rat). 

So far this process has been lovely. it works well and makes both storing and accessing these ideas a joy. But did I mention there's no sync?  

Now, I always have my phone with me. There's pretty much never a moment when I am phoneless these days. Maybe on a Sunday morning in the brief interim before I've transferred iPhone to jammies, but that's about it. Since Vesper is currently an iPhone-only app, sync is not a huge problem. If I need to access my Malcontent ideas, I get my phone. No biggie.

But sometimes I work on Malcontents on my iPad. And when I do, it might be nice to not have to look over at my phone for the ideas or the dialogue. It might be nice to see these things — drawings and text — all on one device. So: sync. 

As time's worn on, and as I've become more and more invested in Vesper as a creative tool, I've hoped more and more for sync. With the advent of iOS 7, Q Branch — the company behind Vesper — released an update. And when it contained no mention of sync, I started to worry a bit. 

So I was extremely pleased this morning to read on Daring Fireball that sync is the next big milestone for Vesper. Vesper has turned out to be a terrific tool for me without sync, but sync will make it even better. Mr. Gruber refuses to give an exact timeframe for the feature, and that's okay. Just knowing it's on the horizon is, frankly, good enough for me.

I'm very much looking forward to it.

 

Mailbox Revisited

I take it all back. 

Well, maybe not all of it, but I have found a use — a thing I love about it, even — for the popular iPhone mail client Mailbox. 

I wrote about Mailbox back in February, and not altogether flatteringly. And while I still think there are problems with the basic premise of the app, and I stand by my conclusion that it's not the be-all end-all of mail clients, I recently fired Mailbox up again and discovered something about how I access email. 

It turns out that I don't read most of it. 

You see, a huge amount of my mail is short notifications of one sort or another: someone emailing to say they're out sick, a server notifying me of a change, that sort of thing. These kinds of message can be read quickly right from the preview list of the mail client and then filed away forever. And that's something Mailbox excels at.

In the past, getting an email like this would require me to do two things: 1) open the email to mark it as read, and; 2) archive the email. But now, using Mailbox, I can do both steps in one easy swipe, because Mailbox's swipe both archives the message and marks it as read. It doesn't sound like much, but when you get a ton of this sort of email — and I certainly do — it really adds up.

I still don't really like reading longer emails, or responding to emails in Mailbox. It just feels not right somehow. Anything that requires more effort than filing away I'll do in another mail client. But for simple scanning and archiving of basic notification-type emails, Mailbox has saved me tons of time and effort.  It's now the first stop in my email management workflow.

Torch Browser Bad

If you ever start seeing alerterdaemon crash logs in your Console, you've probably installed the Torch Browser at some point. Maybe you were just curious to try a browser with a media bias; maybe you wanted to see this new flavor of Chrome; maybe you'd heard it was a good way to download videos from YouTube. I don't know, and I'm not one to judge.

torchbrowser.png

After seeing these logs, you get curious, you start poking about a bit more and discover that alerterdaemon lives here:
/usr/local/libexec/alerterdaemon

demons.png

You Google this /usr/local/libexec/alerterdaemon and there are no results. None. Whatsoever. And now you're getting nervous.

no_results.png

So you start sleuthing. This daemon was modified on July 30th. What else was modified on July 30th? Well, not that much, it turns out. But there is an application in my Applications folder called Torch with that same modification date. I still have the installer, so I run it, command-i the thing and it tells me that all it installs is Torch.app in /Applications. 

torch_bom.png

I'm here to tell you, my friends, that that is an outright lie.

A find command for the date in question reveals that the Torch installer installs a veritable buttload of junk all over the filesystem. There's stuff in /Library, there's a bunch of things in your home account. Oh, it's a scene, man, a real mess. And, yes, there's even:
/usr/local/libexec/alerterdaemon

I wanted to post about this for a couple reasons. Firstly I just want to say shame on the Torch browser installer team. You provide an installer that lies about what it installs, and you provide no uninstaller. This is a terrible practice that undermines the trust of your potential users, which I count myself no longer among.

Second, I wanted there to be some search results for this alerterdaemon. There's nothing scarier than Google finding nothing. It is truly terrifying. Hopefully this post will remedy this particular instance.

Thus ends the PSA. Please resume your regular activities.

Update

A reader emailed me asking how I managed to remove all Torch-related errata. Here's what I did.

First I got the modification time of alerterdaemon:
ls -la /usr/local/libexec/alerterdaemon -rwxr-xr-x 1 root wheel 294980 Jun 18 15:16 /usr/local/libexec/alerterdaemon

Then I did a find for everything on my boot drive that had the same modification time. You'll need to figure the number of days ago Torch was installed and enter that numer for the -mtime option. For the grep part enter the modification time pulled from ls. Finally, I specified the -x option to prevent traversing devices other than the boot drive:
sudo find -x / -name "*" -mtime 98 -ls | grep 15:16

Then I just went through and deleted everything that looked like it was part of the Torch install.

Also, here's the result of that command. This is pretty much everything I can determine that was installed by the Torch installer. Bear in mind, this is an older version, and things will likely have changed significantly in newer versions of their installer.