This ends well - because I have backups. Other than the necessity of backups, the main lessons of this post are;
- Aperture 3.2.1 Libraries can become corrupted.
- Aperture 3.2.1 has some wicked bugs.
- A few debugging tips.
- It is unwise to edit in Aperture until all import processing is completed.
- How to manage when disaster strikes
This morning I did a routine import of 30 or so CR2 images from my Canon T2i using Aperture Import. Import completed normally. As images were post-processed I worked on some red-eye editing. I mis-clicked somewhere, and the spinning pizza of death appeared. About a minute later Aperture crashed, leaving this crash log ...
Process: Aperture [75650]
Path: /Applications/Aperture.app/Contents/MacOS/Aperture
Identifier: com.apple.ApertureVersion: 3.2.1 (3.2.1)
Build Info: Aperture-201094000000000~2
Code Type: X86-64 (Native)
Parent Process: launchd [41554]
Date/Time: 2011-11-25 09:15:19.689 -0600
OS Version: Mac OS X 10.6.8 (10K549)
Report Version: 6
Exception Type: EXC_BAD_ACCESS (SIGBUS)
Exception Codes: 0x000000000000000a, 0x0000000138d4d000
Crashed Thread: 23
I tried five more times. Each time Aperture opened normally, and about 30 seconds later, presumably as it resumed image processing, it crashed with the same error.
I knew I had backups, so I didn't have to panic. In fact, I have three backups:
- Encrypted image with Carbon Copy Cloner to local drive nightly. This is a drive clone of course, but CCC also saves changed and deleted files in a 'just-in-case' folder. So it's a Clone+.
- Encrypted image with Carbon Copy Cloner in my office that's 3 weeks old (offsite).
- Time Capsule backup to a 2TB drive upstairs.
It was easy to demonstrate that the problem was in the Library. I option-launched Aperture and created a new Library. It was fine. I also removed my Aperture Preference files and Aperture still crashed on Library launch.
As an experiment I used EasyFind to locate the images I'd imported. I'd renamed them on import ("_Thanksgiving_") so it was "easy to find" them using EasyFind's package search option. I moved them out of the Aperture Library. This time it launched normally.
Whatever was wrong with Aperture, it was something related to processing the images I'd imported that morning -- or a problem with the images themselves.
I then used ImageCapture [1] to bring in the suspect images from my SD card. There were no problems. I added these to an empty Aperture Library. No problems.
By then my 45GB restore had completed so I put the images into the restored Aperture Library. No problems. Just to finish the cycle off, I again performed the red eye correction associated with the big crash. No problems.
One experiment I didn't do was use Aperture First Aid to repair or rebuild the Aperture database. Speaking of that kb article, I suspect this paragraph is relevant to my problem ...
...If Aperture does not open, it may help to defer creation of previews. Press the Shift key immediately after you start Aperture to prevent preview generation for that session. If a damaged image in your library is preventing normal opening, this may allow you to start Aperture...
i don't think the original images in my Library were damaged, but I do think something went wrong with Aperture's preview creation. Actually, I have a hunch that the problem is related to Aperture's face processing -- the EasyFInd recovery process I experimented with returned a number of face "thumbnails' -- but only a number. As though face thumbnail processing was not completed.
I hope the fixes I've outlined here will help others. The bottom line - be sure you have a full backup of your Aperture Library. I prefer two fully automated backup methods that have almost nothing in common. Backups are too unreliable to trust a single backup method.
[1] This app has its own really annoying bug. When used it stores the path it last saved images to. If you change drives it keeps asking for the old drive -- and tries to mount it. Dumb. Easy to delete preferences to fix.
Update: Terence Devlin - an Apple guru, also suspects the Faces process.
Update 12/20/2011: I suspect it was due to bit rot (bad sectors) on my drive.
6 comments:
I am facing the same crashes - what ultimately saved your library?
It's in the post Ohmar.
I restored from backup.
I did show, however, that I could remove all the images associated with my last import INCLUDING the .jpg face snapshots, and that also worked.
Encrypted image with Carbon Copy Cloner to local drive nightly. This is a drive clone of course, but CCC also saves changed and deleted files in a 'just-in-case' folder. So it's a Clone+.
Interesting. I'm a long-time user of SuperDuper! which doesn't have this feature. Maybe time for a chance …
Do you encrypt all your backups or only those that are stored at another location?
Encrypted backups are a difficult trade-off between more safety and security and less reliability.
My onsite Time capsule backup isn't encrypted, but my CCC backup is.
You can make your own encrypted image and use that with SuperDuper (I used to) but CCC incorporates that into the process.
I used to use SD!, but really CCC is easier to use, less troublesome for me, and has some nice added features.
I rely now solely on CCC for my external backups and it has worked smoothly so far, especially the triggered backups if source/destination get connected are great.
I am still struggling with the backups for my family and my office. Time Machine backups are a beginning. Cloud backups work too, although they are not helpful if you need a fast and full restore. In addition, they come with bandwidth issues ('fair use'). We use both nevertheless.
How do you switch your drives for external backups, i.e., how do you avoid (if at all) to have all your backups at the same location at the same time?
I backup the server and my main workstation to CCC, and I rotate my 2TB CCC drives offsite every few weeks. It's not perfect; a house fire or similar disaster could still cost me weeks of data.
My Time Capsule backup doesn't go offsite and it backs up all the machines to an internal and external drive. I could live without the data on those machines though, so I tolerate lack of offsite backup for them.
Post a Comment