Sandboxed Preferences for Aperture
I was looking to trash my Mail.app preferences this morning and I know I’d looked before, and hadn’t found them. The file used to be com.apple.mail.plist and located in ~/Library/Preferences/ however that file no longer exists (and if it does, it’s just a holdover from a previous OS). Finally today I found a discussion online that explained because Mail.app is a “sandboxed” app, that the preferences have moved to a new location. And what else did I find in this new location? An entire Aperture folder I did not previously know existed!
Aperture’s sandboxed folder
The sandboxed folder is located in ~/Library/Containers/com.apple.Aperture/ and within there is loads of stuff that frankly I don’t know what is all about yet. There’s a container.plist file, then a Data folder and within that, a series of aliases mimicking your home directory. On mine there’s a single JPG file just hanging out there (no idea what that’s all about) a Documents folder (not alias) containing an alias to an iChats folder — maybe because I dragged a photo from Aperture to iChat/Messages once?
More interestingly, if you look in the Library folder you’ll find an Application Support folder, and in there the *.apcommands file that had gone missing for many in one of the post Aperture 3.3 upgrades. You’ll also find *.plist files for various plug-ins to Aperture. Looking in the actual Preferences folder here you’ll find tons of aliases to other preference files, more *.plist files for other plugins, presets for all those plugins that we lost when this sandbox update didn’t handle the migration to sandboxed very well, and bafflingly, an alias to the com.apple.Aperture.plist file, the original of which still lives in the ~/Library/Preferences/ where it used to.
Any software engineers out there who’d care to shed some light on why we see so many seemingly irrelevant aliases in here, and why the Aperture preference file itself is not in the sandbox folder?
Comments
on December 14, 2012 - 4:13am
This may or may not be related to this newly discovered folder. Nevertheless it may be useful since there seems so little information available on how recent Aperture updates are changing its behavior.
My primary Aperture library on my desktop Mac, which remains on all the time, is set to automatically import Photostream images as they appear. Traditionally, the import occurred whenever I launched Aperture.
Yesterday I created a screen grab on my iPhone, and deleted it from the camera roll and Photostream almost immediately. When I launched Aperture this morning, the screenshot appeared imported into the monthly Photostream project but not in the Photostream itself.
This behavior suggests that the Mac cached Photostream additions in almost real time. And I’ll bet they were buried in this new container folder. Whereas earlier versions of Aperture seemed to import images via the Internet connection upon launch.
Bob
on December 14, 2012 - 6:49am
The whole folder structure is related to Aperture being sandboxed now. Sandboxed Apps can only access specific folders by default. To access other files or folders, the user must allow it manually via Open/Save panel. These Apps need ‘special’ preferences folders as well, and each app is allowed to access its own preferences folder by default. The preferences are located in ~/Library/Containers/[com.appdomain.appname].
Sandboxed Apps also need a way to keep track of any file the user allowed to access. My guess is, that Apple handles that by using different types of symlinks in the application specific preferences folder.
For example, look into
~/Library/Containers/com.apple.Aperture/Data/Pictures(which refers to the Pictures folder in your home-directory). There you can access all files inside this folder directly (because Aperture is allowed access to your Pictures folder by default). Then look into~/Library/Containers/com.apple.Aperture/Data/Library. There you’ll find lots of folder-aliases (to which Aperture has at least no write access) and some ‘real’ folders like Caches which Aperture can fully access.You can read more about sandboxing in OS X in Apple’s official documentation:
Apple Developer Documentation - About App Sandbox and Apple Developer Documentation - Designing Your Sandbox
on June 15, 2013 - 12:10am
So to clarify on this thread, is there anything that can be safely removed from this ‘container’?
I am operating at the moment on a secondary machine, being my laptop with limited space and the container is clocking 90GB in size, which seems extreme considering it’s my understanding it’s not the photo library itself. I guess I was hoping there was some spring cleaning I could do safely.
For the record, I am currently working off the MASTER LIBRARY file dragged over from my desktop system onto an external hard drive.
Any advice would be most appreciated.
on June 15, 2013 - 1:38am
WD,
90GB is massive!! Is that 90GB just for the com.apple.Aperture folder in ~/Library/Containers, or is it the entire Containers folder? My com.apple.Aperture folder is only 26MB, and the entire Containers folder is 465MB. So I’d say something is wrong.
Before trashing anything, can you identify just WHAT is that big? Drill down and figure out what’s taking all that space and let us know.
-Joseph @ApertureExpert
• Have you signed up for the ApertureExpert mailing list?
•• Have you picked up your copy of the Nik Collection for just $126? This deal won’t last forever!
@PhotoJoseph
— Have you signed up for the mailing list?
on June 15, 2013 - 3:07am
Massive is just what I thought, so glad I’m not alone in that.
It breaks down as follows:
com.apple.Aperture = 94.7GB
Inside that:
Container.plist = 115KB
Data = 94.7BG
Old Data = 4KB
The very large “Data” folder has inside:
- Small file sizes ‘aliases’ to several folders (Desktop, downloads, pictures, movies, music)
- A 5MB sized Library folder (with many sub-folders inside)
- And a 94GB “Documents” folder, which contains many folders with raw camera files in them. Best can tell these folders represent photos I have previously imported on my laptop (over the years), but have merged into my main desktop library via “export > project as library” methods. In short, they are no longer needed on my laptop as they exist on my external drive in the MAIN LIBRARY file.
One other interesting fact I have just discovered is that if I start a new Aperture library without my external hard drive plugged in, the new library automatically starts importing all these files from the “Documents” folder, re-creating the projects I have previously imported via my laptop.
In theory I feel I’d want to delete all the raw files in this “Documents” folder, but fear any consequences, not understanding the “Containers” structure. Any advice on this would be much appreciated.
I am happy to supply any more info if needed.
Thanks in advance!
on June 15, 2013 - 3:53am
WD,
Very interesting. I wonder if it’s a crash recovery.
Personally what I would do is let it do a complete import as you described. It may well be moving the files, not copying them. Then you can look at that new library and see if you recognize anything you don’t have elsewhere, and see if anything needs saving. Probably not from what you’re describing so then just trash it. Or to be really safe, copy that to another drive, wipe out the RAW files in the Containers folder (unless they’ve already been moved), and once all that’s out of there and unplugged from your system, go ahead and connect your regular drive and make sure that no Originals are missing (you can do a search for missing Originals). The key here of course is to ensure that you don’t have any referenced files where the only Original is in that Containers folder.
-Joseph @ApertureExpert
• Have you signed up for the ApertureExpert mailing list?
•• Have you picked up your copy of the Nik Collection for just $126? This deal won’t last forever!
@PhotoJoseph
— Have you signed up for the mailing list?
on June 17, 2013 - 7:19am
I backed-up and deleted the files and everything seems to be connected fine, so in the end these appear to be unnecessary copies. Not sure how they got there in the first place, but I’m glad to have discovered them and am now glad to be rid of them, saving almost 100GB on my laptop’s flash drive, where space is always precious.
Thank you Joseph for your quick and clear guidance. It’s sincerely appreciated.