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: Peter Lübke <email@hidden>
- Date: Sun, 27 Mar 2011 12:30:46 +0200
Am 26.03.2011 um 16:41 schrieb Matt Neuburg:
On Fri, 25 Mar 2011 12:08:53 -0700, Laurent Daudelin
<email@hidden> said:
I've been trying to copy items from a local disk to an AFP-mounted
volume with "copyItemAtPath:toPath:error:" and I found it to be
unreliable in the sense that it will fail to set the modification
date of the item copied to match that of the original item. It
doesn't report any error, just silently continues.
I'm curious as to how
performFileOperation:source:destination:files:tag: does with this.
But I don't hold out much hope.
Also, cp now handles resource forks okay, and it has a -p option
that preserves dates. So that might be another thing to try.
In my own application, which relies on mod dates (it syncs
folders), I had so much trouble with all this that in the end I
resorted to Apple events telling the Finder to perform the copy -
and then more Apple events to fix the mod dates afterwards. In
recent versions of the system I've been able to eliminate the mod
date fixing part; the Finder now gets this right. Of course this
relies on the Finder running.
Still, wasn't the big advertisement for copyItemAtPath supposed to
be that it does the same thing the Finder does? So if it fails to
do that, that would be a bug.
I don't believe that copyItemAtPath preserves Spotlight Comments, so
anyway it does not the *same* thing the Finder does. Or am I wrong on
this?
Peter
_______________________________________________
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