Re: copyPath:toPath:handler: more reliable than copyItemAtPath:toPath:error: ???
Am 26.03.2011 um 16:41 schrieb Matt Neuburg: On Fri, 25 Mar 2011 12:08:53 -0700, Laurent Daudelin laur...@nemesys-soft.com 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 (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
Re: copyPath:toPath:handler: more reliable than copyItemAtPath:toPath:error: ???
On Mar 27, 2011, at 03:30, Peter Lübke wrote: Am 26.03.2011 um 16:41 schrieb Matt Neuburg: On Fri, 25 Mar 2011 12:08:53 -0700, Laurent Daudelin laur...@nemesys-soft.com 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? I haven't checked yet for this. But, getting the file copied properly was my main concern. I haven't tried the NSWorkspace either. It would be hard to provide any feedback using the workspace to do the copy, though. Haven't looked at cp either because I got what appear to be a winning combination with copyPath:toPath:handler: and FSSetCatalogInfo() to fix any remaining modification dates that were not set by copyPath:toPath:handler:. -Laurent. -- Laurent Daudelin AIM/iChat/Skype:LaurentDaudelin http://www.nemesys-soft.com/ Logiciels Nemesys Software laur...@nemesys-soft.com ___ 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
Re: copyPath:toPath:handler: more reliable than copyItemAtPath:toPath:error: ???
On Fri, 25 Mar 2011 12:08:53 -0700, Laurent Daudelin laur...@nemesys-soft.com 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. m. -- matt neuburg, phd = m...@tidbits.com, http://www.apeth.net/matt/ A fool + a tool + an autorelease pool = cool! Programming iOS 4! http://www.apeth.net/matt/default.html#iosbook___ 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
copyPath:toPath:handler: more reliable than copyItemAtPath:toPath:error: ???
I've been struggling with this for a few days and I can't find any resolution. 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. However, if I use the (deprecated as of 10.5) copyPath:toPath:handler:, this method will leave much less files with incorrect modification dates but will also return NO if it can't copy something properly. It will not, as with copyItemAtPath:toPath:error: send the handler the fileManager:shouldProceedAfterError: but at least, in some cases, it will return NO after the copy, so I can try to act on it. The copies that end up with incorrect modification dates will vary from each run I do. I have found that, based on my experiment, you need to be copying at least 1000 items for the error to show. I'm assuming that if you have not a lot of items to copy, you are less likely to see the error. So, for now, I seem to be stuck using the older copyPath:toPath:handler: because copyItemAtPath:toPath:error: is unreliable at best. I also lose the ability to have an update for the actual items being copied specially if I'm copying a folder containing other folders and files. This is happening with 2 different remote Macs. They are both running 10.5.8. One is an Intel iMac, the other a PowerPC Xserve. I have full permissions on both remote machines. I examined the original files and folders containing them for which the copies didn't have their modification dates set properly and didn't find anything different in the permissions than the other copies that had their modification dates set correctly. 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. Has anybody else noticed this? -Laurent. -- Laurent Daudelin AIM/iChat/Skype:LaurentDaudelin http://www.nemesys-soft.com/ Logiciels Nemesys Software laur...@nemesys-soft.com ___ 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
Re: copyPath:toPath:handler: more reliable than copyItemAtPath:toPath:error: ???
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? -- Sean McBride, B. Eng s...@rogue-research.com Rogue Researchwww.rogue-research.com Mac Software Developer Montréal, Québec, Canada ___ 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
Re: copyPath:toPath:handler: more reliable than copyItemAtPath:toPath:error: ???
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. -- Laurent Daudelin AIM/iChat/Skype:LaurentDaudelin http://www.nemesys-soft.com/ Logiciels Nemesys Software laur...@nemesys-soft.com ___ 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
Re: copyPath:toPath:handler: more reliable than copyItemAtPath:toPath:error: ???
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. -- Laurent Daudelin AIM/iChat/Skype:LaurentDaudelin http://www.nemesys-soft.com/ Logiciels Nemesys Software laur...@nemesys-soft.com ___ 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/garywade%40desisoftsystem s.com This email sent to garyw...@desisoftsystems.com ___ 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
Re: copyPath:toPath:handler: more reliable than copyItemAtPath:toPath:error: ???
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? I just completed various runs using the 3 different APIs: copyItemAtPath:toPath:error:, copyPath:toPath:handler: and FSCopyObjectSync. In order of reliability, for those interested, from the most reliable to the most unreliable: 1. copyPath:toPath:handler:, leaves usually less than 5 files with incorrect modification dates. 2. FSCopyObjectSync, leaves usually between 10 and 20 files with incorrect modification dates. 3. copyItemAtPath:toPath:error:, the worst of all: out of 1060 items to copy, leaves 834 with incorrect modification dates. However, it's consistent. From what I can tell observing over 800 different items, it's always the same items that have incorrect modifications dates. Another thing I did notice. Since I want this copy operation reliable and depend on the modification dates being set properly, after the copy, I run a few NSOperations to fix those modification dates using FSSetCatalogInfo(). After that fix (which amazingly doesn't raise any error when it cannot set the creation and modification dates of a file), I still get files that have their modification dates incorrect! What I did observe after several run is that some copy methods seem to leave the copied items in better shape than others when I apply the FSSetCatalogInfo() to those. Again, here is a score after several runs of the copy API that perform the best to the worst for the FSSetCatalogInfo: FSCopyObjectSync: 1 file after using FSSetCatalogInfo() still remains with incorrect modification date. copyItemAtPath:toPath:error:: 1 file after using FSSetCatalogInfo() still remains with incorrect modification date. copyPath:toPath:handler:: no file after using FSSetCatalogInfo() to fix incorrect modification dates. -Laurent. -- Laurent Daudelin AIM/iChat/Skype:LaurentDaudelin http://www.nemesys-soft.com/ Logiciels Nemesys Software laurent@nemesys-soft.com___ 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
Re: copyPath:toPath:handler: more reliable than copyItemAtPath:toPath:error: ???
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
Re: copyPath:toPath:handler: more reliable than copyItemAtPath:toPath:error: ???
On Mar 25, 2011, at 3:46 PM, Laurent Daudelin wrote: I just completed various runs using the 3 different APIs: copyItemAtPath:toPath:error:, copyPath:toPath:handler: and FSCopyObjectSync. Two things: 1. Have you checked if the Finder achieves a copy that's correct in the sense you require? 2. Have you tried the copyfile() low-level routine? http://developer.apple.com/library/mac/#documentation/Darwin/Reference/ManPages/man3/copyfile.3.html 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
