OmniFocus 2 (Mac App Store) is now available. In general, I am finding it to be well designed. The menus and options are refined and simplified. It’s a bit less flexible than previous versions, but I think it’s more approachable.
The beta’s problems with low information density remain, though you can somewhat mitigate them by clicking this link to enable the experimental “compact” layout. Even with the single line layout, the window makes less efficient use of space. For example, in OmniFocus 1 there were 219 pixels from the left edge of the window to left edge of my actions. In OmniFocus 2, with the narrowest possible sidebar, it’s 387 pixels. The minimum font size is also larger, so the actions themselves show less text in the same width.
The text itself is now set in ApproximaNova, rather than a font of my choosing. So there’s no way to get high-quality unsmoothed text like I could with Osaka. With font smoothing, the text looks fuzzy on a non-Retina display. They gray note text is especially hard to read.
You can use OmniFocus 1 and 2 simultaneously, since they are sync-compatible. This is interesting for comparing the design, as well as the speed. Some actions, such as flipping views, are faster in 2. Arrow-keying through projects and contexts is much faster in 1. Moving actions up and down has always been slow and still is.
Many of the screenshots show OmniFocus in full screen mode. Indeed, it doesn’t seem to have been designed for small windows. If you have the sidebar or inspector hidden, showing them can grow the window off the right edge of the screen, and hiding them doesn’t always put things back the way they were.
I like the redesigned inspector, but the resizing problems could be avoided if it were available as a popover or floating window. Like the iPhone version, there are now buttons to quickly defer a task for a day, week, or month. I prefer to use a script bound to a keyboard shortcut.
The manual—which is well done—is now available on iBooks. Unfortunately, the Mac version of iBooks doesn’t support scroll wheels and has a distracting animation when paging via the keyboard. The app has a built-in HTML-based help viewer that works better, except that it isn’t searchable. A PDF, with page thumbnails and easy searching, would probably be best.
The app seems to be pretty solid for a new release. The main bugs that I noticed are:
- The “Go to Search Field” menu item and keyboard shortcut don’t always work.
- Services no longer work in the outline when whole actions are selected (just text). I’ve posted a script that works around this so that you can still bulk-open URLs.
- The Control-D binding for Forward Delete no longer works at all in the outline. I’ve long used that to delete actions so that I can keep my right hand on the mouse.
- You can no longer drag and drop actions onto contexts in the outline.
Design Font Smoothing iBooks Mac Mac App OmniFocus
Arq recently reported hundreds of GB of missing files, across multiple backup targets. This is so at odds with Amazon Glacier’s reputed 11-nines durability that I’m guessing it’s due to an application bug. It would not surprise me if the files are still there; Arq just isn’t seeing them. In any event, my strategy is to have multiple cloud backups—Arq and CrashPlan (which has been working very well recently)—so this got me thinking about possibly adding a third.
The obvious choice is Backblaze. It has a native Mac app, is developed by ex-Apple engineers, and sponsors many fine podcasts.
I’d previously been hesitant about Backblaze because of the way it handles external drives. I’ve read about problems with large bzfileids.dat files sucking RAM and preventing backups entirely once they get too large. It’s also worrisome that it only retains deleted files for 30 days—meaning that a file is truly lost if I don’t notice that it’s missing right away. And if, for some reason, my Mac doesn’t back up for 6 months, Backblaze will expunge all my data, even if my subscription is still paid-up. The situations in which my Mac is not able to back up for a while are exactly the ones in which I (or my survivors) would want to be able to depend on a cloud backup!
My other concern is that Backblaze doesn’t actually back up everything. It fails all but one of the Backup Bouncer tests, discarding file permissions, symlinks, Finder flags and locks, creation dates (despite claims), modification date (timezone-shifted), extended attributes (which include Finder tags and the “where from” URL), and Finder comments. Arq, CrashPlan (as of version 3), SuperDuper, and Time Machine all support all of these. Dropbox supports all of them except creation dates, locks, and symlinks.
As a programmer, I especially care about metadata. But I think most users would as well, if they knew to think about it. For example, losing dates can make it harder to find your files (i.e. they disappear from smart folders or sort incorrectly), even leading to errors (i.e. not finding the correct set of invoices for a time period). You would never use a backup app that didn’t remember which folders your files were in, so I don’t know why people consider it acceptable to lose their Finder tags. (If you use EagleFiler, it can restore the tags for you.)
Some people don’t care much about metadata. Macworld’s survey of online backup services didn’t mention it. Neither did Walt Mossberg. (He also told readers that Backblaze automatically includes “every user-created file”; in fact, it skips files over 4 GB by default.) [Update (2014-05-25): The Sweet Setup doesn’t mention metadata, either (via Nick Heer).]
Backblaze has a stock answer when asked about Backup Bouncer:
This actually tests disk imaging products, a bad test for backup as items we fail on shouldn’t be backed up by data backup service.
Some people accept this explanation. I think it’s misguided and borderline nonsensical. True, Backup Bouncer tests some rather esoteric features, but Backblaze fails the basic tests, too. It would be one thing to say that there’s a limitation whereby dates, tags, comments, etc. aren’t backed up, but they’re actually saying that these shouldn’t be backed up. As if products that do back them up are in error. So presumably Backblaze doesn’t consider this a bug and won’t be fixing it.
Lastly, it’s a shame that Backblaze isn’t up front about what metadata it supports. Some users are technical enough to investigate these things themselves. Others will have read the excellent Take Control of Backing Up Your Mac and seen its appendixes, which give Backblaze a C for metadata support. But most Backblaze users won’t know that a poor choice has been made for them until they need to restore from their backup.
Update (2017-08-23): A Backblaze employee responded to this post:
Backblaze absolutely backs up and restores the “file creation date” and “file last modified date”. With these two caveats: Backblaze is only accurate down to Milliseconds (1/1,000ths of a single second) if you restore by USB hard drive restore, and only accurate to the second if you prepare a ZIP file restore. The latter is because that is a limitation of the ZIP file format.
The tool “Backup Bouncer” fails Backblaze on this test, and it irritates me. I feel “wronged” by this. The new APFS Macintosh file system has the ability to set the file creation date down to one BILLIONTH of a second, and I assume that just to be totally difficult Backup Bouncer gleefully sets every last bit.
I’ve asked for clarification, but as far I can tell the response is spreading incorrect information and seems to misunderstand various of the issues involved.
I started a Backblaze trial in order to verify the claim that the creation date is preserved, but I was unable to get an answer because 4 hours after Backblaze says that it backed up my test files, they were still not showing up in the restore interface, even though it purports to show the latest files as of this minute. After 5 hours, the files were available, I restored them, and the file creation dates were lost and changed to the modification date. The Backblaze restore also messed up the files’ modes, making them executable when they had not been.
Update (2017-08-24): Backblaze support explained to me that it’s normal for there to be a delay, which can be from 1–8 hours, before the files are actually available for restore. This is because, although the file data has been sent to the server, the server can’t access the files until the client has sent the index that describes the changes. It typically waits a few hours before doing this. What this means is that, during those hours, the Backblaze client reports that the backup is complete (“You are backed up as of: Today, 7:28 AM”), but it’s actually not. If your Mac breaks or goes offline (i.e. you pack up your MacBook for a trip) before the index has been uploaded, it’s as if the backup never happened. I assume the delay before sending the index is some sort of optimization, so perhaps it’s justified, but I consider it a major bug that the client reports the files as backed up when you can’t actually restore them (no matter how long you wait).
The Backblaze employee replied about the file creation date issue. The gist of it is that the dates are not preserved when restoring via the network. However, you can pay $99 (flash drive) or $189 (hard drive) for them to mail you your data, and in this format the dates will be preserved. If you mail the drive back (sounds like you have to pay shipping) they will refund the cost. I have not verified that this method works, however, I can confirm that the index file that’s sent to the Backblaze server contains the correct information for the creation dates.
Update (2017-09-03): See also: Accidental Tech Podcast.
Update (2018-02-05): aikinai:
I started getting emails warning that all of my external drives were offline and my data would be soon deleted. Instead of “Very sorry about that, here’s how to fix the issue,” I got this long response about the ways their system looks for new files in serial and it can get jammed and start ignoring everything, with no apology, no acknowledgement this was their issue, and no solution. I had to go fishing for solutions and drag the information out of them to finally figure out what I needed to do. Which it turns out is to get back an internal drive (totally unrelated to the other drives Backblaze abandoned) I had physically removed and repurposed, put it back the computer, wait a long time for Backblaze to see it, then uncheck that drive in Backblaze and remove it again.
[…]
The client will lie to you and you never know what’s really backed up. Even if you use the secret alt-click to force a full drive scan, it can still miss files and tell you fully backed up when files from days ago are still nowhere to be found. Luckily I’ve never actually needed to do a restore, but I almost thought I did one time and would have been furious at all the missing files I noticed.
Update (2022-03-07): Backblaze (via Adam Engst, Hacker News):
Backblaze has always kept a 30-day version history of your backed up files to help in situations like these, but today we’re giving you the option to extend your version history to one year or forever.
Daniel Jalkut:
I recently learned that
@Backblaze’s 1 year extended backup doesn’t work the way I (or my brother, who ran into this) expected. I thought it was “everything just like 30 days plan - but for a year”. Instead, if you haven’t attached a drive for 30+ days you have to RE-UPLOAD it.
So the day is RETAINED for 365 days, but if you have a slow or expensive bandwidth connection, you have to make sure to re-attach drives <30 days or else you have to re-upload. Even though they have the files? Disappointing. My laziness was counting on it behaving otherwise.
Tim Wood:
I love* it when
@backblaze
says I’m fully backed up and I double-check a (non-excluded) file and see it doesn’t show up in the restore interface. Cool.
Amazon Glacier Arq Backblaze Backup Cloud CrashPlan Extended Attributes Mac Mac App Metadata SuperDuper Top Posts
