Wild, it's more like what one would read on a geek site.
Turns out it can be done more or less safely. Problem is you need an external drive that ignores permissions -- or you can use a disk image in the shared item folder.
Is this some kind of sign that iLife '09 will support multiple iPhoto Library merges?
Ok, so I'm grasping at straws.
Update 3/9/09: The article was revised 1/12/09. I think they added a disk image option to turn off permission checking. If you go the disk image route remember that the standard disk image is hell on backups. Every time you change one byte in a 40GB Library the whole image has to be backed up. Sparse bundle images mitigate this problem, but Retrospect doesn't back up sparse bundle image backup properly (Time Machine does).
I might try this in a folder where my wife and I both have read/write privileges, though I'm concerned Apple didn't mention this obvious solution. I'll want to verify that this actually happens:
Keep in mind that while one user is viewing this library from iPhoto, another user will not be able to open this library at the same time. Instead, an alert message appears indicating that the library is already in use. You will need to quit iPhoto from the other user account before the next user will be able to view or edit this library.Update 3/9/09b: Ok, I see the problem. It has to do with the way OS X (BSD Unix) manages permissions and it's a deep problem. Even if I create a shared folder and move my Pictures there, each file inside the "Library" (package) is still mine alone. Even if I change permissions on every file so "Parents" can edit them, newly added images will still get one or the other user's permissions. Yech!!
So to share a Photo library between multiple users you really do need to use something that ignores permissions -- or you need a future version of OS X -- or you need to use the Mac OS X Hints ACL hack.
Update 3/10/09: No changes with iPhoto. As I wrote on this Discussion thread, I think the problem is deeply embedded in the design of OS X (BSD Unix?) file sharing:
I don't think this is something that iPhoto can fix, it's really more of an OS problem. I THINK that the problem goes something like this:Interestingly the Apple kb article seems to imply that images ignore permissions. Thinking about how they're used, I bet that's true. Oddly enough, I can't find good google hits on this.
1. OS X assigns new files permissions associated with their owner.
2. OS X allows only one owner per file.
So even if one set all the permissions on thousands of Library files to a multi-user group, the first time someone added new items to the Library there would again be inaccessible files.
Using an external drive or a disk image works because one can then ignore permissions, thereby eliminating a vast amount of security as well!
It's really a fairly deep OS problem. I wonder if Snow Leopard tries an alternative approach. I think XP file sharing doesn't have this particular problem, but I can't say for sure.
Alas, I can't go the sparsebundle route because my backup software (Retrospect) needs an update to manage these appropriately.
Update 3/19/09: I'm told Retrospect treats the Sparse Bundle as just another package. I'm doing some testing; after copying an iPhoto Library to the Sparse bundle I have:
Original iPhoto Library: 3.7 GBiPhoto editing in the Sparse bundle library can be hard on backups. I changed a rating on a single image, and five bands were revised (40MB of dat to backup).
Sparse Image Bundle version: 3.8 GB in 488 8MB bands (view package contents)
Now I need to see how Retrospect behaves.
Incidentally, even though file privileges are ignored on this image, they still exist. So if you let multiple people work on Library, then move it to drive where privileges are NOT ignored, won't the Library be trashed until all privileges are corrected?
This feels like a nasty hack to work around a really bad file system design.
Update 4/9/09: Supposedly Apple has secretly fixed this in iLive '09!
Update 5/6/09: I updated another post with information about Retrospect and sparse bundles based on informed comments. It doesn't look good to me.