Ugh, this bug was so nasty to track down… Apparently if you call this family of methods a couple of times it screws up whether NSBundle can find resources in the future. My specific situation is that I would call this method to find what bundles are in a directory. I would then run it one more time (because that is how the code is laid out). Then when kqueue tells me that something has changed in that directory (because I added a new bundle to the target directory) I call it one more time. It finds the new bundle just fine, but for some reason it completely ignores the stuff in Resources/ when trying to query the contents of said new bundle! I don’t know if this is the result of some errant caching or what but it is consistently reproducible. The old bundles work fine but there is nothing that can make Cocoa see the contents of this new bundle. This is a big problem because it means that [NSBundle loadNibNamed:owner:] now can’t find any nibs in the new bundle (which was what first tipped me off to the problem). In the current Developer Tools Documentation under the entry for [NSBundle pathsForResourcesOfType:inDirectory:] there is a statement:

Note: This method is best suited only for the occasional retrieval of resource files. In most cases where you need to retrieve bundle resources, it is preferable to use the NSBundle instance methods instead.

I hope that is not implying this weird (caching?) behavior. Also, after the damage has been done NSBundle instance methods no longer work either. The solution to this has been to instead use a UNIXy way like scandir() to find out what bundles are in a directory. Not nearly as graceful, but at least I don’t have weird peripheral behavior. So anyway…fair warning to all against using these routines.

This entry was posted on Monday, August 27th, 2007 at 8:19 pm and is filed under Bugs, Programming. You can follow any responses to this entry through the RSS 2.0 feed. You can skip to the end and leave a response.