I'm starting to apply the iOS 4 Data Protection to the files my app uses. I'm concerned about the possibility of setAttributes:ofItemAtPath:error: failing to apply the changes: is there a discrete set of known reasons why this method fails? I don't have a good fallback behavior in case the attribute cannot be set since it needs to be set for commercial reasons, so I'd like to know if I should worry about the call failing.
I've never heard of a situation in which it does fail, and most of the ones I can think of would be catastrophic for the device in general (they involve the encryption hardware being offline, at which point the root filesystem can no longer be used). If the act of converting a file requires additional disk space or memory, then I suppose it could fail for lack of those reasons: however I think it's all done in-place and out-of-band by the dedicated encryption hardware so I doubt it needs either of these things.
Your fallback strategy should depend on your risk analysis. Painting very broad brush strokes, which is more important: confidentiality or availability of the data you're trying to store in the file? If it's confidentiality, then if you can't protect the file you should give up trying to save it. If it's availability, you should save the content anyway. Anything else you do (reporting or auditing any failures; falling through to a self-supplied encryption technique etc.) also needs to fit with your threat model.
Remember, if confidentiality of your data is important enough to encrypt it, you should create the protected file before you write into it. If you take a plaintext file and convert it into a protected file, there's a finite chance of an attacker retrieving the plaintext still. If that's an important attack to you, you should be trying to avoid it.