Re: Strange NSFileManager file replacement issue
Re: Strange NSFileManager file replacement issue
- Subject: Re: Strange NSFileManager file replacement issue
- From: Sixten Otto <email@hidden>
- Date: Fri, 19 Aug 2011 07:17:51 -0700
On Thu, Aug 18, 2011 at 10:38 PM, Ken Thomases <email@hidden> wrote:
> 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.
>
If true, that certainly makes that method far less useful in the general
case than I expected, and really seems restricted to the "saving a new copy
of an in-memory document and swapping it" case. I really don't want to put
the in-process download into the Documents tree. (Both because it's
potentially visible to the user through iTunes, and because
NSTemporaryDirectory() will be swept up occasionally.) I'll see what I can
do to test this this morning.
I guess the question then becomes:
- Abandon the use of the atomic swap altogether, and roll my own
copy+remove?
- Or introduce an extra step, where I copy the temp file into
NSItemReplacementDirectory,
and then call replaceItemAtURL?
- Or is there some better pattern altogether?
> 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.
>
Definitely. I want to verify that I *can* make it work if the replacement
item is already in the Documents tree / replacement directory, and then I'll
be spending some time on the bug reporter.
Sixten
_______________________________________________
Cocoa-dev mailing list (email@hidden)
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:
This email sent to email@hidden