Mac OS X’s Finder: Badly needs a smarter ‘Copy’ command

Posted by Pierre Igot in: Macintosh
May 29th, 2006 • 1:06 pm

There is one fundamental problem with the way that the Finder’s “Copy” command works that Apple has made no effort to improve over the years. And it has to do with the way it handles multiple copy commands effected in quick succession.

In a nutshell, the problem is that the default Finder behaviour for multiple copy operations is to run them in parallel. In other words, if you start one copy operation, and then, while that first copy operation is still in progress, you start another one, the Finder attempts to run the two operations in parallel.

Depending on what you are copying and where you are copying it to, this can have rather disastrous consequences.

Consider the following scenario: Yesterday, I had two 1 GB files on a DVD that I wanted to copy to my hard drive. Instead of selecting the two files and then dragging the selection to the hard drive, I selected the first one and dragged it to the hard drive, and then I selected the second file and dragged it to the same hard drive.

When I did that, the Finder started running the two copy operations in parallel, as was illustrated by the progress dialog box, which had two sections with two progress bars, one for each copy operation.

The problem is that a CD or a DVD player is not a very fast device (compared to a hard drive). And it definitely does not like having to do multiple things at the same time! The two copy operations running in parallel actually cause the drive to constantly jump from one file to the other one and back, reading a bit of this one, and then a bit of that one, etc.

It’s something that you can actually hear the drive do. When you are only copying one file, the copy operation runs smoothly and all you can hear is the constant whir of the DVD player. But when you are copying two files in parallel at the same time, you can hear the drive’s laser head constantly jumping from one section of the DVD to another and back.

The end result is that, instead of having two copy operations that go half as fast as a single one, you have two copy operations that go something like 1/10th as fast as they would if they were the only operation taking place!

This is obviously a very inefficient and wasteful way to do things. It seems to me that the Finder should be smart enough to realize that, in the end, the two copy operations can be completed much faster and much more efficiently by doing them in succession, and not in parallel.

But our good old Finder is not that smart, and has never been able to do this. Instead, it just wastes a whole lot of time and energy trying to run things in parallel, probably decreasing the life expectancy of the drive significantly in the process.

The situation with the DVD drive is just one extreme illustration of the problem. But it’s the same when doing long copy operations from hard drive to hard drive or from partition to partition on the same hard drive.

When you want to manually back up your stuff on an external hard drive, for example, and the stuff you want to back up is scattered in many different locations (which is most often the case, especially given the way that Mac OS X itself organizes your important files in its “Library” folders, etc.), then it is tempting to start one copy operation after the other. But it’s not a good idea. You can end up having half a dozen copy operations running in parallel in the Finder, and the combination of these operations ends up being much slower and generating much more useless hard drive activity than successive operations would do.

What the Finder needs is some kind of “queue” for copy operations, where successive copy commands would be lined up in sequence and completed one after the other. Of course, there should still be a way to by-pass this and run copy operations in parallel if one so desires—but copy operations running in parallel should be the exception rather than the norm.

6 Responses to “Mac OS X’s Finder: Badly needs a smarter ‘Copy’ command”

  1. MHinton says:

    This is a very good idea and the UI for it would not be that difficult. Multilple copy operations would default to serial with each operation listed in the copy dialog. Then each pending copy could have a little icon that when clicked would break out the operation into a parallel copy.

  2. Pierre Igot says:

    For the record I submitted this idea to Apple as a desirable “enhancement” a while ago, and they gave me the canned reply “the feedback you provided is known to engineering and a solution is currently under investigation.”

    At least they didn’t give me the canned “behaves as expected” reply, so I guess all hope is not lost that one day, this idea will actually be implemented. And you’re right: It wouldn’t be all that difficult to implement in the UI.

  3. Tr909 says:

    I would like to mention as a side note that the copy behaviour should take into account if files are from same source drive and/or to same destination drive. Some information about the drives should be present. Like, a fast external firewire drive can easily accept files from DVD and internal drive at the same time. Or another instance, where you copy something between external firewire drives and in parralel from DVD to internal drive. Just to queue everything would also not be a smart algorythm.

  4. Tr909 says:

    Addendum, maybe when starting a copy process it could try-out a parralel and/or serial-copy to check throughput/per/second. Allthough nifty this might be error-prone. This genuinly is not an easy task and steering it might require knowledge and intervention by the end-user, which OTOH is something which might easily might lead to problems (which apple has to support again).
    I Guess some coder might test out these things with an easy/small queing program.

  5. Tr909 says:

    Almost 2 years on, i’m copying tens, twenties and 40-ies of gigabytes around to clean up my harddrives, so that i could update to Leopard. So i googled for “multiple copy”-commands and “queue”, etc. and it came back with this betalogue-page where we were discussing this already in 2006… You found a solution, Pierre?
    Seems like in 2007, others were also wondering about this queue clue…
    (via )

  6. Pierre Igot says:

    No sign of any improvement as yet.

Leave a Reply

Comments are closed.