View Full Version : Finder vs. cp ... FIGHT!

06-03-2002, 08:04 AM
Anyone know how Finder copies files?

It clearly doesn't use the cp command. Using Memory Monitor to watch the two processes, cp just fills all available memory, until it has to page out (so does ditto), but Finder copy doesn't seem to create so much as one inactive page.

It's kind of bugging me that cp seems to snatch all available memory (yes, I know this is another memory thing - don't hit me avi ;) ), but Finder can make copies "transparently" - I'd really like to harness this "low overhead" copier for scripting.

Any ideas? Would AppleScript do the trick?

06-03-2002, 12:00 PM
I don't know how transparent it is. The Finder isn't multithreaded yet, so my guess is you won't see the individual details in your memory usage. It's just encapsulated in the Finder's memory allocation. It may use CpMac but that may require Developer tools and since that isn't installed standard??? don't know. May have to wait for Jaguar to see the individual stats.

06-03-2002, 03:22 PM
i imagine the finder copy is just performing the old OS9 routines carbonized. read file, send to disk driver, flush memory, groan, lather, rinse, repeat.

cp no habla resource forks, finder does.

CpMac is deprecated; don't use it, it has lots of problems. ditto MvMac.

as for scripting? hmm, does finder have 'copy' in its applescript lib? ...

from finder dict: finder basics:

copy: (NOT AVAILABLE YET) Copy the selected items to the clipboard (the Finder must be the front application)

of course, one should be suspicious of all documentation. try it and see.

06-03-2002, 08:50 PM
hmm. I tried a CpMac vs. Finder Copy vs. Ditto vs. cp thump-fest.

In fourth place comes cp - no resource forks, generally my copy (of my library) got smushed.

Third up is ditto. It does the job, but damn that's a memory hog. Seems to copy the entire source to memory (regardless of how much is left "free") THEN dumps it out to the destination. Quick, reliable, but dang, it's dirty.

Second we have Finder Copy. Checked in Terminal, and all the resource forks are there. The problem with Finder Copy is it requires me to drag'n'drop: not an easily scriptable action, unless I write a note to remind me :p Benefit is that it seems to copy "on the fly" - files are put into destination as they are read into memory, so the overhead is minimal.

First up seems to be the new boy (to me, anyway) CpMac. Looks like Finder Copy (as far as my system seems to care) in that it doesn't crap all over my free RAM, but is scriptable. And to boot, it copies resource forks by default.

However, merv says it's deprecated, and I shouldn't use it. Care to expand, merv? I assume you mean that it may not be in future revisions, but deprecation is usually preceeded by replacement. Is ditto the replacement? Or is this a "deprecated as in abandoned" moment?

06-03-2002, 09:01 PM
JayBee, if you search the forums for "cpmac" you'll find several threads that explored it, and this one...


determined it was to be avoided for numerous reasons; lack of docs, doesn't handle links, et. al.

you should read thru them all and come to your own conclusions, but i wouldn't trust it with my dog's data.

06-03-2002, 11:19 PM
Originally posted by JayBee
Seems to copy the entire source to memory (regardless of how much is left "free") THEN dumps it out to the destination. Quick, reliable, but dang, it's dirty. Think of it as efficient. Imagine the opposite, read one byte and then write one byte to disk, repeat. I don't think you would argue that you would have your disk chattering like a (hmm don't know what, but it would be chattering!).

So, where do you draw the line, if you read then write 1024 bytes, 2048???

If you have the memory (and I would let the OS worry about that) then the best way *is* to suck it all into memory and then write it all out.

Interesting that the source code on the darwin web site shows a check for:


And if true it uses memory mapped file for the io but if not, it uses chunks of MAXBSIZE:

while ((rcount = read(from_fd, buf, MAXBSIZE)) > 0) {

I ran this:
printf( "MAXBSIZE = %d \n",MAXBSIZE);

and got
MAXBSIZE = 131072

So it looks like copy should just use a 128K buffer for copying. Maybe it is filesystem cache that is consuming your memory?

06-03-2002, 11:38 PM
I've always used the command "duplicate" in applescript to copy a file.