Betalogue

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.

This entry was posted by Pierre Igot on Monday, May 29th, 2006 at 1:06 pm and is filed under Macintosh. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.