In Mac OS X 10.4 Tiger (PPC edition), the only UI difference between a block-level copy and a file-level copy when using Disk Utility’s Restore (a.k.a. disk cloning) mode is that the progress bar label reports "Copying Blocks..." for the former and just plain "Copying..." for the latter. The difference is significant, especially for full-disk cloning operations.
To invoke block-level copy, you:
- must not be booted from either the source or the destination partition – the Mac OS X DVD is good for this, if you do not have a different partition.
- must tick the checkbox for Erase Destination when setting for Restore mode in Disk Utility
- may or may not need to select “Skip Checksum”.
Unfortunately, the progress bar message confirming whether a file-level or block-level copy is displayed after one has already invoked the Restore procedure, and there isn’t a “Cancel” button anywhere in sight. As if potential for hours of time wasted (and quite possibly loss of metadata, since asr in file-copy mode doesn’t bother preserving such trivial things as file creation date) isn’t good enough to warrant a button to express one’s regret.
One wonders why Apple did not simply put in a simple checkbox for “Block-level copy”, and warn you about the requirements for block-level copy (and further, asking you if you wish to proceed with file-level copy anyway if you don’t meet the requirements.)
Probably because they thought (in their infinite Apple wisdom) that it would scare and confuse the “normals” who can’t tell the difference. Never mind that the people who would try to clone their entire drives for backup (as opposed copying files here and there to a USB key) are probably savvy enough to care.
Wonder if this changed in Leopard.
Update
Many seem to arrive at this post wondering what a block-level copy is. Here it is in a nutshell. A typical hard disk is divided into a linear set of n logical blocks, m bytes each. In short, your files are recorded within these blocks. To keep track of things, the filesystem is responsible for maintaining more metadata on top of this. This lets it create such niceties as “folders”, and forms the overall tree of folders nested within folders that you see in Finder.
A file-level copy means that the copying program loads in the directory tree and walks the tree. When it finds a directory, it’ll load metadata to find all the files contained in it. When it finds a file, it’ll go look for the blocks that contain the file’s data, and start copying. This has a lot of overhead, since the program has to load in the nice tree abstraction first, descend into each folder looking for files to copy, and then go find the proper blocks to copy, and then finally copy the data and any metadata associated with it. A block-level copy, on the other hand, recognizes that if you literally want to copy everything from one disk to another, it’s a lot easier and faster to just start copying at block 1 until you get to block n at the end — rather than running up and down that directory tree.
A block-level copy is a literal byte-for-byte (well, one would hope) copy of one disk to another, while file-level copying creates a copy of each file and folder from one disk to another. The distinction here is subtle but important. A file-level copy from disk A to B does not necessarily result in A == B, while a block-level copy (for all intents and purposes) does. As for performance, for a full-disk clone, block-level copying should be dramatically faster than file-by-file copying.
The Leopard version of Disk Utility now has a Stop button for canceling block copies, so Apple listened in part, but there’s still no checkbox to tell Disk Utility whether to do a file or a block copy before it begins. It’s more important to have a Stop button, so at least we can be grateful for that, but people are still expected to find out somehow that block copies will take place if you tell Disk Utility to erase the destination volume.
Though many people at Apple are clever, listen to suggestions and bug reports, and produce wonderful stuff (most of Disk Utility is decent enough), some people who make decisions at Apple (even the same people with the aforementioned positive attributes) often behave no differently than many people everywhere: they can be only partially budged from their existing ideas.
At least, in this sense, Apple is no different from many other companies (and individuals). And they’re actually better than many, much of the time. Still makes one wonder, with Apple’s resources, why they don’t just implement more of our sensible suggestions more often.