Believe it or not, I don’t plan for every post here to be about Pear Note. Some will be about my opinions of things, and some, like today’s, will be about developer topics. So, if you’re not a software developer, you probably won’t get too much out of this post.

Pear Note uses QuickTime for recording and playback of audio/video. I recently ran into a problem that drove me crazy for some time, so I thought I’d share what I discovered here for other developers to learn from.

I’ve been implementing an import feature to allow users to import external media into Pear Note. In some cases, this called for replacing a QuickTime movie file on disk with a new one. So, I would remove the old file (using NSFileManager) and write the new one. This usually worked, but sometimes when I tried to create a new QTMovie from the newly written movie file to play it, I would get a “No such file or directory” error. The file was definitely there, but QTMovie didn’t think it was. More interestingly, if I just waited for a few seconds, the problem went away.

I did a lot of digging, and discovered that QuickTime uses the Carbon File Manager (CFM) to access files. If you’re using HFS+ (or several other filesystems), CFM actually goes through volfs to access these files. I confirmed this by running a trace using the File Activity template of Instruments. Instruments showed me something interesting that explained what was going on. Files accessed through volfs are named with the corresponding inode number on the HFS+ filesystem. Since I was deleting one file and creating a new one with the same name, I expected the inode number to change. Indeed, ls on the files confirmed this. However, QuickTime was trying to access the old inode, not the new one.

Why, you might ask? I’m just guessing, but I’d bet the Carbon File Manager can’t handle two open files with the same name. I had the old file open from playing the old QTMovie. Why didn’t I just close the file? Well, QTMovie doesn’t exactly give you a close method. I presume it closes the file when the object is destroyed. I’m using garbage collection, so I just had to wait a couple seconds for the garbage collector to run and then QTMovie would suddenly be able to see the file that was there all along.

The workaround to this that I’m using right now is to just run the garbage collector manually. It’s not the best solution, but it works. Hopefully QuickTime X in Snow Leopard (which is supposed to be a major overhaul of QuickTime) will move QuickTime beyond CFM. In the mean time, maybe this post will help other developers who have QuickTime tell them a file doesn’t exist when they know that it does.

This entry was posted on Friday, November 7th, 2008 at 9:18 pm and is filed under Development. You can follow any responses to this entry through the RSS 2.0 feed. Responses are currently closed, but you can trackback from your own site.