Gather ’round children, for a tale of a technological, and chronological trainwreck.
It was a dark, and stormy night…
…I was working on trying to bring some old Aperture Libraries into Capture One, and the imports were failing, with an error:
Catalog import failed. The Library is currently open.
Checking Capture One’s support site yielded only a support article about a lock file, but it was for Capture One catalogues not Aperture libraries.
What I should have done right here is file a support request with Capture One, wait for an answer, and stop work.
That sentence is in the voice of me as the protagonist narrator, over a still frame of me about to do the thing I most definitely should not have done.
What I did, as the footage resumes playing, was to try troubleshooting, so I could provide Capture One’s support people with an isolation of the problem.
My first thought was that the problem may be because the Aperture libraries that were failing were those which I had exported from my main Aperture catalogue running on my Mac Mini, while it was accessing images on a drive shared over the network from my Mac Pro workstation. Ok, so booting up the Mac Mini, enabling File Sharing on the Mac Pro, and then enabling the file Sharing user’s access to the photo drive…
Re-exporting the libraries confirmed the problem wasn’t a one-off.
Eventually, what I realised is I had to export the library to a local folder on the Mac Mini, then copy it to the Mac Pro. From there, the library opens fine in Capture One.
So, the problem is that when Aperture writes the library to a network location, it leaves a lock file in place, which trips up Capture One.
Problem solved; I exported all the particular libraries I wanted to re-process to a local drive on the Mac Mini, then copied them across to the Mac Pro, shut the Mac Mini down, and went to go back to Capture One on the Mac Pro.
I filled in a support ticket with Capture One’s support staff, to see if they’d encountered the problem, as I hadn’t been able to see it described in their support site.
As an aside; If you’re setting up a support site for a piece of software, why not try structuring your knowledge base of answers based upon the menu structure of the program. So if I have a problem with the function File > Import Catalogue > Aperture Library, let me navigate to that and see all the issues related to importing Aperture Libraries.
Knowing I wouldn’t need to continue having file sharing on, I disabled it, and then removed the sharing user from the Photo drive permissions.
Then Time Machine began to run… and continued to run… a lot longer than it usually does. Once it had finished, I noticed that rather than the 1.5TB of free space my Time Machine drive should have, there was now only 80GB of free space. Thinking backwards, the horror of what had happened began to dawn upon me (is this sounding like The Martian where he shorts the probe with the drill?).
By performing a recursive addition, and then removal of a user permission from my photo drive, I’d somehow caused Time Machine to think the entire drive needed to be backed up afresh. That may not have been so bad, except for a decision by Apple engineers; on a 4TB drive, there should be a minimum of 80GB of free space on a Time Machine backup. So despite the entire new backup fitting within the space available on the drive, Time Machine deleted two months of my oldest backups to free up that extra space.
I went into the commandline, and using the tmutil command, removed the new giant snapshot, but unfortunately that didn’t liberate any space on the drive. I ran Time Machine again to see if it would do the same huge backup a second time, and it didn’t, but still no liberation of space. Deciding I was tired of fighting with it, I decided to take the drive (and it’s twin which had avoided the problem) out of service entirely, they’re now stored in split locations having served only 14 months of use.
So, I brought in a new pair of drives, 8TB this time, and we’ll see if Time Machine can behave in a more orderly fashion this time around.
Eventually I heard back from Capture One’s support folks; the Aperture lock file is located in the Library’s package contents in:
Database/apdb/lockfile.pid
Removing that file solves the problem.