Re: copyPath:toPath:handler: more reliable than copyItemAtPath:toPath:error: ???
Re: copyPath:toPath:handler: more reliable than copyItemAtPath:toPath:error: ???
- Subject: Re: copyPath:toPath:handler: more reliable than copyItemAtPath:toPath:error: ???
- From: Laurent Daudelin <email@hidden>
- Date: Fri, 25 Mar 2011 15:17:12 -0700
Hello Gary.
Thanks for pointing out the errors in my FSCopyObjectSync. I did fix the code and, right now, it shows as this:
- (BOOL)copyItemAtPath:(NSString *)srcPath toPath:(NSString *)dstPath
{
OSStatus osStatus = noErr;
BOOL isDir = NO;
BOOL result = NO;
FSRef sourceItemRef;
FSRef destDirRef;
FSRef destItemRef;
OptionBits flags = kFSFileOperationOverwrite | kFSFileOperationSkipSourcePermissionErrors;
NSString *destName = [srcPath lastPathComponent];
NSString *destDirectory = [dstPath stringByDeletingLastPathComponent];
result = [FolderSweeper refForPath:srcPath outRef:&sourceItemRef isFolder:&isDir];
if ( ! result)
return NO;
result = [FolderSweeper refForPath:destDirectory outRef:&destDirRef isFolder:&isDir];
if ( ! result)
return NO;
osStatus = FSCopyObjectSync(&sourceItemRef, &destDirRef, (CFStringRef)destName, &destItemRef, flags);
if (osStatus != noErr)
return NO;
return YES;
}
After many runs of testing, it seems to be a little better. Better in the sense that it still leaves copies of files that don't have the right modification date still doesn't report any error, but when I run FSSetCatalog() after doing the copy, all files modification dates are correctly fixed. So, it seems on par with "copyPath:toPath:handler:", although "copyPath:toPath:handler:" seems to leave less files with incorrect modification dates and sometimes, I say "sometimes", it will return NO meaning that there was a problem copying one of the item.
So now I'm left to pick between "FSCopyObjectSync" and "copyPath:toPath:handler:". If I want to update my process sheet while the copying is being done, I would have to use "FSCopyObjectASync" but I'm not sure about how to correctly schedule the callback since this call is running from an NSOperation. If I can get "copyPath:toPath:handler:" to call "fileManager:willProcessPath:" to work reliably to tell me which file it's about to copy, I'll probably opt for it since it would seem more straightforward to use. Plus, it's in Cocoa and, speed-wise, I haven't seen any difference really between FSCopyObjectSync and "copyPath:toPath:handler:".
Once I seem to have a reliable solution, I'll take time to build a little example that shows the problem and will file a bug with Developer Support. It seems that these APIs are seriously flawed. They fail to accomplish the task described in the documentation (if the tasks in the documentation are wrong, then the documentation is wrong) and, worst of all, they won't return any error when they can't accomplish the task. So, either way, it seems to me that there are bugs with all of them. I wish someone from the Cocoa Frameworks at Apple would comment but I guess it's their prerogative to just observe and not make any comment.
Still, if someone could confirm that they might not perform reliably when copying to an AFP remote volume, I would stop pulling my hair and would sleep better at night...
-Laurent.
--
Laurent Daudelin
AIM/iChat/Skype:LaurentDaudelin http://www.nemesys-soft.com/
Logiciels Nemesys Software email@hidden
On Mar 25, 2011, at 13:33, Gary L. Wade wrote:
> You may have missed this point in my previous replies about this, but have
> you identified anything in common with the objects that did not preserve
> the modification dates, such as were they folders, symbolic links,
> aliases, plain-old-files? Remember my mentioning how symbolic links throw
> a kink into the mix if they become followed vs. used in place and my
> comment about creating an FSRef using the not-follow-symbolic-links
> option. Also, I'm pretty sure you want your flags in your sample code to
> use a bit-or, not a bit-and, and you had duplicated one mask.
>
> On 03/25/2011 1:20 PM, "Laurent Daudelin" <email@hidden> wrote:
>
>> On Mar 25, 2011, at 12:13, Sean McBride wrote:
>>
>>> On Fri, 25 Mar 2011 12:08:53 -0700, Laurent Daudelin said:
>>>
>>>> If that makes any difference, I'm running the copy method from an
>>>> NSOperation but each copy is done sequentially. I thought about
>>>> creating
>>>> one NSOperation for each item to copy in a given folder but thought
>>>> that
>>>> was many not very wise.
>>>
>>> Maybe you're seeing a weirdo threading bug, what if you try everything
>>> on the main thread?
>>
>> Just did a couple of runs in the main thread. Besides being almost unable
>> to update my progress sheet and the app totally non-responsive, no change
>> in the results. There are still copies that didn't have their
>> modification dates set properly. And they vary from one run to the other.
>>
>> It is just totally weird. I just can't understand why the failures and
>> how poor those methods are performing on Apple Filing Protocol volumes.
>> As it is now, there are *NO* API for me that can reliably copy items from
>> a local disk to an AFP remote volume. My last resort would be to use "cp"
>> in an NSTask, but I don't want to do that. I have tried
>> "FSCopyObjectSync", "copyPath:toPath:handler:" and
>> "copyItemAtPath:toPath:error:" and they all fail randomly.
>>
>> I'm going to submit a bug but I'm surprised that these issues are unknown.
>>
>> -Laurent.
>> --
_______________________________________________
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