Re: Least Expensive File Copy Method?
Re: Least Expensive File Copy Method?
- Subject: Re: Least Expensive File Copy Method?
- From: Ondra Cada <email@hidden>
- Date: Sun, 1 Sep 2002 14:21:59 +0200
On Sunday, September 1, 2002, at 06:44 , Buzz Andersen wrote:
I'm looking to deal with file copy operations that may involve large
numbers of files, large amounts of data, and a lot of time. Ideally, I'm
trying to limit the impact of such operations on the Finder and my own
application. To this end, I have detached an NSThread to allow the
operations to happen asynchronously, and this helps a lot in terms of
avoiding the dreaded "beach ball."
Even still, copying all of this data tends to have a very negative impact
on my Mac's responsiveness. Maybe this is unavoidable (now that I think
about it, I don't remember ever sitting around using Photoshop while
copying a gig worth of files through the Finder :-) ), but if anyone
knows of a better way (perhaps a more low-level method?) to do the copy I'
d like to know.
Well, you can decrease somewhat the copy thread priority: that would make
the copy slower, but the computer would stay more responsible meantime.
So far, I have tried these two methods:
The NSFileManager way:
[fileman copyPath: source toPath: destination handler: self];
The NSWorkspace way:
[workspace performFileOperation: NSWorkspaceCopyOperation source: source
destination: destination files: files tag: tag];
This is top-level GUI-based copy; in principle, it just says to the system
file manager (which happens to be Finder currently) to do it all for you.
Although you might suppose that the system file manager's copy would be
better optimized than the one of yours, at least in current Mac OS X it
definitely does not apply.
Of the two, the File Manager seems to have the least impact on the system
(I send NSWorkspace the "noteFileSystemChanged:" after the copy to make
sure the copied files show up). Again, though, if there is a better way,
I'd definitely like to know!
I haven't tested it, but I *suspect* that cp -R *might* be the most
effective easy method: try to run it through an NSTask (well, for starters,
try to run it directly from Terminal and measure the time ;), and you'll
see. The most effective method absolutely would be probably using the
lowest BSD API even better than cp does, but I don't recommend it, unless
you have *plenty* time for optimizations.
Also, in case there is some non-trivial probability that your app would
copy files inside-volume and that the result contents would not be changed,
do check, and if so, make hardlinks instead of copying. A hardlink is,
unlike softlink or alias, a true "twin" of the original file; its only
limitations are
- that it can't span volumes;
- that it share the file contents, so a change applies to all hardlinks.
Finally, beware that those low-level methods do not support resource forks.
Generally it is all right, since the stuff's obsoleted anyway, but if you
use Classic and Carbon apps often, they alas still keep appearing.
---
Ondra Cada
OCSoftware: email@hidden
http://www.ocs.cz
private email@hidden
http://www.ocs.cz/oc
_______________________________________________
cocoa-dev mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.