On Aug 18, 2011, at 11:24 PM, Sixten Otto wrote: > - The download of the new data to a temporary file in NSTemporaryDirectory() > finishes successfully. > - I calculate the path I want to copy it to. > - I see that there's already a previous version of the file at that path. > - I try to use -[NSFileManager > replaceItemAtURL:withItemAtURL:backupItemName:options:resultingItemURL:error:] > to > swap in the new file. > > That method returns NO for failure, so I check the error... but it's nil.
This is something of a guess: The documentation for -replaceItemAtURL:withItemAtURL:backupItemName:options:resultingItemURL:error: is a bit vague in its description of the newItemURL parameter: > The item which will replace the originalItemURL. This item should be placed > in a temporary directory as provided by the OS, or in a uniquely named > directory placed in the same directory as the original item if the temporary > directory is not available. Although it is easy to interpret "a temporary directory as provided by the OS" being compatible with NSTemporaryDirectory(), I suspect it really means a directory returned by -URLForDirectory:inDomain:appropriateForURL:create:error: with NSItemReplacementDirectory passed for the directory and your ultimate destination URL passed for the "url" parameter. My thinking is that -replaceItemAtURL:... is a wrapper around exchangedata() or FSExchangeObjects(). Those functions, and the general operation that they perform, require that the files to be exchanged be on the same file system. It would seem that, on iOS, the application's Document folder is on a different file system from the temporary directory. This is exactly the problem which -URLForDirectory:NSItemReplacementDirectory... is intended to solve. It's to give you a temporary directory that's appropriate for a subsequent -replaceItemAtURL:... call. For what it's worth, I can reproduce this on Mac OS X (Snow Leopard 10.6.8), when the two files to be exchanged are on different file systems (a.k.a. volumes). I recommend that you file bugs against the documentation for not adequately explaining the requirements on the newItemURL parameter and against the implementation for failing to provide a valid NSError pointer on failure in this case. Regards, Ken _______________________________________________ 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
