I got bitten today by the fact that Objective-C strings in Cocoa programming are not the same things as plain old C strings. The problem is that Objective-C is essentially an object-oriented veneer on top of plain old C; sometimes it matters that you remember this, and other times it doesn’t. This was one of the times it mattered.

A little background. A while back I wrote and released ExportToArchive, a somewhat useful plugin for iPhoto. It allows you to select photos from your iPhoto library and export them into a few different archive formats. About three days after releasing it, I got an email from a guy who had just tried to export his entire library, 756 photos, into a single archive. He was perplexed because iPhoto just seemed to hang/lock up. The problem was that when I wrote the thing, I never considered that anyone would try to archive more than a few photos at a time. Thus, once you made your selections and started the export, I copied each file to a temporary directory, and then archived the copies. That works great for 10 or 20 photos, but not so well for 756.

The answer to that problem was not to copy the files, but to make a symlink of each photo into that temporary directory and then archive the files by dereferencing the links. It’s still going to take a while to archive the photos, but there will no longer be a copy phase, which should make things faster.

Which leads to today’s adventure. There’s not a native Obj-C or Cocoa method to create a symlink. There is a method on NSFileManager called linkPath:toPath:handler: but that creates a hard link, which won’t span file systems. So I was forced to use the C function symlink which takes two arguments: the source path and the destination path. This seemed easy. I would pass the absolute path name to the original file as the source argument, and the generated name for the link as the second. Easy-peasy.

Well, not really. Since symlink is a C function it, like most other C functions, tells you bugger-all about why a failure occurs. The return value when I tried to call it was -1 which means, “something bad happened.” I then had to consult the C value errno to get more info. The value of errno was 22 which, according to the header file errno.h means:

#define EINVAL 22 /* Invalid argument */

An invalid argument. OK. How about telling me which argument is invalid since I did, after all, pass in two arguments.

I tried escaping spaces and quoting the entire string, but nothing worked. Finally, it dawned on me: Objective-C strings are not C strings. symlink was expecting a plain old C string, but I was passing in something completely different: instances of the Obj-C class, NSString. So, the way to fix this was to pass in C strings, and how do you get C strings from NSString instances? Right, call UTF8string on them. Thus my call to symlink went from

rc = symlink(src, dest);

to

rc = symlink([src UTF8String], [dest UTF8String]);

and all seems to be working properly now.

I’m going to do a bit more testing on this, but I will probably release this new version tomorrow.