PDA

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


JayBee
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?

bakaDeshi
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.

mervTormel
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)
copy

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

JayBee
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?

mervTormel
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...

http://forums.macosxhints.com/showthread.php?s=&threadid=762&highlight=CpMac

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.

stetner
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:

VM_AND_BUFFER_CACHE_SYNCHRONIZED

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:
#ifdef VM_AND_BUFFER_CACHE_SYNCHRONIZED
printf( "VM_AND_BUFFER_CACHE_SYNCHRONIZED\n");
#endif
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?

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