03/13/2009 Update: As I explained here, ExportToArchive does, in fact, work with the new iPhoto ’09.

Ever since I switched to my exquisite Mac Pro, I’ve been using iPhoto. A few weeks ago when Apple announced the new iLife ’08, I bought it. Last week while using iPhoto, I wanted to zip up a bunch of photos so I could move them to another machine. But I couldn’t find anything like this in iPhoto. There’s an exporter, but it doesn’t support zip files. You can right-click on a photo and select “Show File”, but that’s clunky and wouldn’t work well if you had multiple files you wanted to zip up.

So I wrote an exporter plugin to handle this. It’s called Export To Archive, and it supports three archive types: Zip, GZip and BZip2, depending on which flavor you prefer. I personally like bzip2, because the compression is much better than the others, but YMMV.

Once you install the plugin, you select the photos and/or events you want to export, then select Export... from the File menu (if using an older iPhoto, the Export... menu item is under the Share menu). The “Export Photos” dialog opens with a new tab labeled “Archive.” Selecting this tab reveals a pane that looks like this.

The dropdown reveals the other two archive types. Select the type you want and then press the Export button. You will be presented with a “Save As” dialog where you can enter the name of the new archive file. You don’t need to specify an extension as the plugin will append the correct extension based on the archive type. After you enter the name you want and press OK, you should see a progress dialog and then you are taken back to your photo library. If everything went as planned, you have a shiny new archive where you told the plugin to put one. If not, you should get an error message telling you what happened.

The plugin does not keep any directory paths that might have existed in your iPhoto library. I considered making a directory for each “event” (iPhoto 7.x only) but I believe a photo can be in multiple events, so this seemed like a bad idea. Maybe later.

Also, if you select multiple photos with the same name (but from different directories, obviously), then I handle it like Safari does when downloading the same file twice. I append an underscore with a number to the filename before the extension. So if you had two files called 100_1234.jpg, then one would be called 100_1234.jpg and the other would be 100_1234_1.jpg. If there were three files, the second would have _2 appended, etc. This seems like a reasonable solution to this issue.

I should mention one more thing about the compression methods. If you use Zip, then any resource fork info is lost. This probably isn’t a problem, but I felt I should mention it. It’s how the /usr/bin/zip program works. If you choose either GZip or BZip2, then the photos are first put into a tar file and then compressed. The /usr/bin/tar program that comes with OSX does preserve resource fork info into the archive. If you look in the archive, you will see that for every file, there is a similarly-named file that is vastly smaller than the original. If you expand the archive on a Mac, then you only end up with the files you asked for. But on other systems, the resource fork “phantom files” will be expanded to the disk along with the photo files. The file names start with ._ so on Unix systems they will be hidden. On Windows, you will probably see them. Either way, it’s extra crud. I tried to figure out a way to get rid of these files, but there doesn’t seem to be one. And maybe we don’t want to get rid of them, anyway. Thus, if you are going to move your archive to another Mac, you might want to choose GZip or BZip2. If you’re going to it to some other system, choose Zip.

Want it? There are a couple of ways to get it, depending on which version of iPhoto you have.

• For iPhoto 7.x (iLife ’08) or iPhoto 8.x (iLife ’09)
  
• For iPhoto 5.x

Both of these installers install the plugin for everyone on the system. PackageMaker.app that Apple provides doesn’t seem to provide a way to install it for just the curent user. This means that the plugin will go to one of two places, depending again on your iPhoto version

• iPhoto 7.x, 8.x: /Library/Application Support/iPhoto/Plugins
• iPhoto < 7.x: /Applications/iPhoto.app/Contents/PlugIns

If you’re running iPhoto 7.x or 8.x and you’d rather install it just for yourself, you can download this zip file and install it by hand. You should put it in ~/Library/Application Support/iPhoto/Plugins.

This is a universal binary. I have tested this on a Mac Pro with iPhoto 7.x and 8.x, and on an iBook G4, with iPhoto 5.x. If you have some other config and it doesn’t work for you, let me know, providing a crash dump, if you have one. I don’t know that I can make it work, but I could look into it.

If you’d like the source code, get it here. You’ll need Xcode 2.4.1 to open the project.

That’s about it. This is free software, released under the GNU GPL. If you like it, tell your friends. If there’s a feature you want, let me know, or implement it yourself and provide me a patch to include in the source.

09/12/2007 Update: I’ve now had two three reports of the plugin not working with iPhoto 6.x. That’s the version I was unable to test with, so if you have iPhoto 6, use caution. And if you have iPhoto 6 and it crashes on you, would you send me the crash dump? It can be found in ~/Library/Logs/CrashReporter/iPhoto.crash.log

09/13/2007 Update: I’ve now had several reports that the plugin doesn’t work with iPhoto 6.x, so if you’re using that version, don’t install it. I am trying to figure out how I can test against 6.x, since I don’t have a machine with that version. Stay tuned for updates.

Uninstallation Instructions
If you need to uninstall, delete the ExportToArchive.iPhotoExporter directory. Depending on the version of iPhoto you are using, it will be in one of two places:

iPhoto 7 or 8

/Library/Application Support/iPhoto/Plugins

iPhoto 5 or 6

/Applications/iPhoto.app/Contents/PlugIns

Delete the ExportToArchive.iPhotoExporter directory from whichever place it’s been installed to, and once you restart iPhoto, you should be fine.

I recently bought the new iWork ’08 suite from Apple and have started using the tools for stuff I used to use NeoOffice for. But I noticed something yesterday that is disconcerting.

Like a lot of people, I store my documents in a CVS repository that is backed up to another disk. I checked in a few documents created with Pages and Numbers, and everything seemed fine. That is, until I re-saved any of the documents.

The problem lies in the fact that a “document” for Pages or Numbers (and probably for Keynote as well) is not a monolithic file like a .doc file from Word. They are directory structures (“bundles” is the Apple term) that the Finder and the applications that use them treat specially. Any program in the /Applications folder is the same type of thing. When you check something into a CVS repository, CVS creates a hidden CVS directory in each sub-directory of the thing being checked in. After checking in one of these documents, I went into the document through Terminal and verified that the CVS directories had been created. So far, so good.

When things went awry was when I re-saved a document. Instead of just changing the necessary files inside the “document,” Numbers deleted and re-created the entire directory structure. Thus, those CVS directories were toast. There’s no good way to recover from this, because those files now look like non-CVS files, but the server already knows about them. To my knowledge, there’s no painless way to handle this situation.

I don’t believe that Subversion is in any better position. When using SVN, you get a .svn directory created in each sub-directory of the document, but those will also get whacked when the document is re-saved. I haven’t tested that assumption, but it seems logical.

I tried to come up with a solution to this, but I’m stumped. I looked into cvswrappers just to see if it could help, but it doesn’t look like it. I also considered a pre-commit script and a post-checkout analog (if there is one), but this didn’t seem like it would really get us there.

The only solution I see is for Apple to stop whacking the directory structure and just change the files inside it that it needs to, and stop molesting the version-control special files. Maybe they can implement this behavior when they add support for OpenOffice and the OpenDocument format…