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
laur...@nemesys-soft.com
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" <laur...@nemesys-soft.com> 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 (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
