# SLOW copy of multiple files



## Sandy McMurray (Jan 10, 2003)

Many OS X users have encountered the frustration of waiting for the Finder to execute a relatively simple action, like moving multiple files from one folder to another. The Spinning Beach Ball of Doom pops up and you wait. And wait. And wait.

I got a painful reminder of this problem this afternoon, while trying to copy approximately 6,000 clip-art images from one folder to another. After a long wait, I relaunched the Finder and gave up.

A quick search of the Discussions area on Apple.com turned up other people who have felt my pain, but only one helpful solution: the idea that I should go into Terminal and use the Unix equivalent of "move all" rather than use the Finder.

So I tried that. Terminal responded with an error message: "argument list too long."

Off to Google, where a search for "Unix" and "argument list too long" turned up some interesting discussions that (I think) give some insight into this problem.

Apparently Unix has traditionally had a built-in limit for the amount of memory that can be used for a program environment and argument list combined. If you try to exceed this limit (e.g. by trying to move or copy too many files at once) you get this "argument list too long" error.

When I tried to move 6,000 files using Unix, it refused. Perfectly normal behaviour for Unix. This response, however, would be unacceptable to a Mac user. Imagine dragging and dropping your files, only to encounter an on-screen error message that says "Too many files. Forget it."

So my guess is that Apple had to work around the problem. It appears that the slowness in the Finder when you drag and drop thousands of files is a direct result of OS X trying to work around a limitation of Unix. I don't know whether OS X works around the built-in limit by juggling or swapping memory around or doing the work in batches. Whatever it does, this clever kludge appears to be what keeps the Finder so busy.

I'm sure there are folks here who know more about OS X and Unix than I do -- does this sound right to you?


----------



## used to be jwoodget (Aug 22, 2002)

No idea (not a unixpert) but you can avoid this by breaking up the copy into smaller segments (i.e. repeated copies of subfolders). Bit of a pain but I find it gets around the slowdown.

I find that I often get copy errors when transferring files between my iDisk and desktop. But that's only involving a few 10s of files.


----------



## TroutMaskReplica (Feb 28, 2003)

why is this sort of thing even happening at all? i thought OSX was supposed to be the world's most advanced operating system? and it can't even transfer files properly? that seems to be the most basic function of an operating system!

i'm in the print industry and haven't yet switched to X. why did apple abandon the simple and elegant OS9 for this horrible candy colored monstrosity? i don't have time to deal with all of these glitches. i'm going to stay in 9 forever....


----------



## jfpoole (Sep 26, 2002)

When you're using <code>cp</code> to copy files, the number of files you can copy at once is limited by the number of arguments you can pass to a command[1]. However, when you're copying files with the Finder, you're not passing arguments to a command, so the argument limit doesn't apply. The only practical limit would be the amount of available memory, I'd imagine.

Why is the Finder slow? My guess is that the Finder is using an algorithm that doesn't scale well against the number of files being copied. Either it's allocating memory poorly or it gathers a lot of information before it starts copying files. I'd have to look at the source to be sure.

Oh, if you get the "argument list too long" error, you can work around it using <code>find</code> and <code>xargs</code> (although <code>xargs</code> seems to be brain-dead on Mac OS X).

[1] This varies from operating system to operating system (it's not just a limitation of Unix). Win9x has a limit of 2048 bytes, while HP-UX has a limit of 2 megabytes.


----------

