OS X Mountain Lion is out, and all Haystack Software apps are compatible:
Arq 2.8.2: online backup to Amazon S3
SyncPhotos 2.2.2: sync your iPhoto Libraries across computers
Duplifinder 2.1.1: eliminate duplicate photos
If you do happen to run into an issue with any of the above, please email support@haystacksoftware.com and I’ll address the issue very promptly!
Both Arq (our backup app)and SyncPhotos (our photo sync app) were bitten this week by the code-signing gotcha that Daniel Jalkut, Ben Artin, and Chris Suter blogged about.
I had switched to using Apple’s new Developer ID scheme for code signing so that when Mountain Lion comes out people will still be able to use Arq and SyncPhotos. I even watched the WWDC video to make sure I was doing it correctly. But apparently I didn’t watch closely enough. As the 3 blog posts linked above explain, the code signatures produced with the new scheme can only be validated by Macintosh computers that have the necessary information to validate them, namely computers running OS X 10.7 or later.
Both Arq and SyncPhotos launched OK on 10.6, 10.7 and 10.8. But on 10.6 they asked for keychain read permission over and over again. This was because OS X couldn’t validate the apps’ signatures and therefore didn’t recognize them.
If you’re working on a Macintosh app and you want to support 10.6, you’ll need to do some extra steps when building it. If you’re not, then the rest of this blog post will be really boring!
For a full explanation of the issue involved, please read the linked blog posts above. They were a great start for me, but didn’t give precise enough step-by-step instructions. In the hope of saving someone else from the hours of trial and error I wet through, I’ve listed the steps I followed below. It worked for me every time. The one crucial difference from the referenced blog posts I think is in step 2, booting into 10.6 before exporting the designated requirement.
codesign -d -r- <path to app>
codesign output that starts with “designated” and store that line in a text file named designated_requirement.txt in the root folder of your project. codesign -f -s 'Developer ID Application: (your company)' \
-r $SOURCE_ROOT/designated_requirement.txt \
$BUILD_DIR/$CONFIGURATION$EFFECTIVE_PLATFORM_NAME/<name>.app
codesign utility:
codesign --verify -vvv <path to app>
codesign --verify -vvv <path to app>
In both cases you should see output like this:
Arq.app: valid on disk
Arq.app: satisfies its Designated Requirement
Arq 2.6.8 is available. To update, pick “Check for Updates” from Arq’s menu.
Please note: Arq 2.6.8 may upload much more than you expect or want it to the first time it backs up. This is due to a bug that I unfortunately created in version 2.6.3. I apologize for this. Please let it finish backing up.
There is no charge from Amazon for data transfer to Amazon, but I realize that re-uploading a lot of data is a long, frustrating experience.
There’s a problem with some of S3′s servers, particularly in the us-west-1 region, but also in other regions. Connections just get “stuck”. Customers were complaining heavily about Arq getting “stuck”. I was initially unable to reproduce the problem, but felt I had to do something to fix it. The Apple networking API that Arq was using had no facility for timing out; plus it was very hard to throttle properly. So I changed Arq to use Apple’s older CFHTTP API.
In my haste to fix this customer problem, I didn’t do enough testing on 2.6.3-4. I screwed up. There was a bug in those releases where some objects were marked as “compressed” but they weren’t actually compressed. So Arq couldn’t restore properly.
What really made things bad was that at some point in my rush to get the issue fixed I accidentally (because of muscle-memory habit) ran the command to publish 2.6.3 in the “update stream” as an official release of Arq, which meant that everyone who happened to check for updates would get this buggy version. I didn’t realize this for several hours. At that point I could only move forward and fix things as quickly as possible.
Since there’s no way for me to tell which objects were compressed, Arq 2.6.5 (and later) ignores all backups made after March 7 by an Arq version older than 2.6.5. I added a “version” to the backup data so that if this sort of thing ever happens again, I can fix it with a less drastic solution.
I’ve also added some “gates” to my release process so that I don’t inadvertently do this again.
Arq 2.6.6 through 2.6.8 contain very small changes — checks for various network errors that were causing Arq to fail the backup instead of retry.
Please let Arq finish doing what it’s doing. It will clean up all the “bogus” S3 data after it successfully backs up everything.
Also, please consider using more than one backup system, as I blogged about in 7 facets of a good Mac backup strategy.
When you’re deciding on your computer backup strategy, make sure it includes a form of “versioned backup.”
Before personal computers, we did our work on paper. The paper approach has a built-in “memory.” If you rewrite a paper document, the old document sticks around until you take action and throw it away. By default you have versioned backup. Even after you throw it away you could still get it back if you’re willing to dumpster-dive and you do it before the garbage truck arrives.
When we switched to personal computers for documents, we lost that “memory.” When you save a new version of your document on your computer, the old version is immediately obliterated — gone forever! It’s unfortunate because having the old versions can be a huge time saver. When you’ve made a mess of things and you want to start over, when you realize you deleted a file that you still need, or when a file becomes unreadable for whatever reason, going “back in time” to get an old version saves the day.
The “trash can” in Windows and OS X isn’t a complete solution, because it only holds onto files you’ve deleted. If you open a document, make some changes, and then click “Save”, the previous version of the document doesn’t go into the trash can.
Apple has tried to provide a form of versioned backup through OS X Lion’s Auto Save and Versions feature. But it only works in apps that have added support for that feature, so it’s not a complete solution.
So, make sure you include a product in your backup strategy that keeps versions. Time Machine (Apple’s built-in backup app) does it for local backups. Arq does it for online backups. Dropbox does it to some extent (it keeps a few revisions of each file).
Cloning tools like SuperDuper don’t do it (but they have other advantages like quick recovery time).
Arq version 2.5 is now available!
This update includes a new feature that posts a Growl notification when a backup completes. It’s useful for folks who hide the menubar icon; now they have a way to know when the backup completes without launching the Arq app. It’s optional — you can turn it off in the preferences.
There are also several bug fixes.
It’s a free update for all Arq users. Pick “Check for Updates” from the Arq menu to get the update.
As always, full release notes for all Arq versions are on the release notes page.
OS X Lion is out, and all Haystack Software apps are compatible.
Arq 1.7.7: online backup to Amazon S3
SyncPhotos 2.0.7: sync your iPhoto Libraries across computers
Duplifinder 2.0.3: eliminate duplicate photos
If you do happen to run into an issue with any of the above, please email support@haystacksoftware.com and I’ll address the issue very promptly!
This release is mostly focused on budgeting. There’s a new view that shows current S3 space usage, and a new menu item to trigger Arq Agent to enforce the budget.
Get the new version by selecting “Check for Updates” from the Arq menu, or download it from http://www.haystacksoftware.com/arq/
Here are the details:
This release adds support for the Asia Pacific S3 bucket region “ap-southeast-1″ and fixes a number of bugs, including excessive memory usage and occasional temporary not-found errors on restore.
Pick “Check for Updates” from the Arq menu to automatically update to 1.3.14, or download it from the web.