Reply from Eskimo1
[quote]OK. From all the reports I’ve seen this is a simulator only problem. If that’s the case, I have a good explanation of what’s going wrong. Here’s a write up I created for a developer who opened a DTS tech support incident about this:
The Mac OS X kernel, which is what the simulator runs on, supports three of variants of stat, known as ostat, stat, and stat64. For this discussion, ostat is irrelevant; what matters here is the difference between stat and stat64. Specifically, stat64 supports 64-bit inode numbers, which means that the size of (struct stat) has changed.
Obviously we couldn’t just change the size of (struct stat) out from underneath existing Mac binaries, so Mac OS X has a compatibility shim that makes this all work. The System framework implementation of stat expects the 32-bit inode version of (struct stat), and we added another System framework routine, stat$INODE64, that accepts the 64-bit inode version. If you build with a deployment target that guarantees the existence of 64-bit inodes, the compiler turns your call to stat() into a call to stat$INODE64.
This only applies to 32-bit Mac OS X builds. For runtime architectures that have always supported 64-bit inodes, like 64-bit Mac OS X builds and iPhone OS builds, there is only one version of stat, and that automatically gives you 64-bit inodes.
You can learn more about the mechanics of this by reading the extremely convoluted definitions in <sys/stat.h>.
Things get tricky on the simulator, however. There are three cases:
A. When you build with the iPhone OS 3.2 SDK, you compile with the 32-bit inode structure and link to the standard 32-bit stat routine from the System framework, and everything is good.
B. When you build with the iPhone OS 4.0 SDK, you compile with the 64-bit inode structure and link with a special stat routine from a custom System framework that’s part of the iPhone Simulator 4.0 SDK [1]. This stat routine automatically redirects your call to the kernel’s stat64 implementation, and everything is good.
C. The problem occurs when you mix and match, for example, you build with the iPhone OS 4.0 SDK, and thus use the 64-bit inode structure, but run with the iPad simulator, and hence get the Mac OS X System framework, and not the special framework from the iPhone Simulator 4.0 SDK. At this point there’s a mismatch between the structure you’re using (64-bit inodes) and the kernel implementation you’re calling (stat, not stat64), and you get gibberish results.
As far as I can tell, this problem only affects the simulator. iPhone OS has always supported 64-bit inodes, so your devices builds see a fully consistent view of the universe.
I don’t think there’s an easy workaround for this problem. Probably the best solution is to build with the SDK appropriate for the simulator you’re testing with. This does mean that, when building with iPhone SDK 3.2, you’ll need to turn off iOS 4 features at compile time (rather than just at runtime, as you will want to do for your device build).
As, as always, if this represents a significant impediment to your development, make sure you file a bug.
[/quote]
Personally, I used NSFileManager from Core Foundation instead, and it works well.