On Apr 14, 2011, at 12:35, Laurent Daudelin wrote: > In my app, I want to provide file operation but try to restrict them if > they're going to fail. I still handle the failures in my code but I feel it's > a better user experience that they know in advance, for example, that a file > is locked and thus I won't be able to delete it or replace it.
I'm wondering about the intent of this thread, though. If you're just venting, then I guess go ahead. Some of us will probably feel your pain. Given that this is a technical list though, it would be nice if such venting posts were limited to one per customer. If you're raising a technical point, then the real question is: what is the API contract for 'isDeletableFileAtPath:'? The answer to *that* comes only from the documentation. This thread finally drove me to go look, and it says (http://developer.apple.com/library/mac/#documentation/Cocoa/Reference/Foundation/Classes/NSFileManager_Class/Reference/Reference.html): > Return Value > YES if the invoking object appears able to delete the file specified in path, > otherwise NO. If the file at path does not exist, this method returns NO. > > Discussion > For a directory or file to be able to be deleted, either the parent directory > of path must be writable or its owner must be the same as the owner of the > application process. If path is a directory, every item contained in path > must be able to be deleted. It seems to me that this is giving you fair warning that the concept of deletability is vague. The only specific promise relates to the writability of the enclosing directory. Everything else is hedged behind "appears to be able". It's possible that the writability of the enclosing directory is the *only* thing it checks. The other place to look is the header file (NSFileManager.h) which (in the 10.6 SDK) has this comment preceding the method in question: > The following methods are of limited utility. Attempting to predicate > behavior based on the current state of the filesystem or a particular file on > the filesystem is encouraging odd behavior in the face of filesystem race > conditions. It's far better to attempt an operation (like loading a file or > creating a directory) and handle the error gracefully than it is to try to > figure out ahead of time whether the operation will succeed. So, the API contract appears pretty clear that the definition of deletability is pretty vague, intentionally to some degree. If you think that the API actually does something different from what's documented, your only recourse is to submit a bug report. If you think that the API should do something different from what's documented, your only recourse is to submit a bug report. There's one thing that's NOT going to happen, though: No Apple engineer is going to read this thread, smack himself/herself on the forehead exclaiming, "Oh, I see what this API should really have been designed to do!" and go change the API. So by all means vent, if that helps, but you've already found your technical answer: that 'isDeletableFileAtPath:' isn't the solution to the deletability check you wish to make. _______________________________________________ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
