You're correct about /sbin and /usr, Charles, but what about /System?
Those are mostly folders, so they can't be compressed anyway. But I would expect all the binary files inside those folders to end up being not compressed, if the restore tool is not preserving the compression.
> The best way to avoid all these sorts of problems is always to click the "Erase Destination" check box when cloning. When using the Restore tab, this will often result in a block copy, which is pretty much guaranteed to be exactly the same as the original.
Does that hold true even if the destination volume has been erased beforehand?
Yes it does. There are a few cases where Restore will fall back to a file copy if it's impossible to do a block copy (such as if the original volume is larger than the destination), but most of the time, if you click "Erase Destination" in Disk Utility's Restore tab, you'll get a block copy. The status bar will tell you which kind of copy it's doing while it's performing the clone, so you'll know what's going on. Since none of the cloning tools out there currently seem to play nice with the HFS+ compression, a block copy in Disk Utility is probably the best way to do a clone for now, as long as the original volume is in good working order (it's also the fastest).
One thing that I do notice, though, is that you mention that you did the clone in Leopard. Since Leopard can't know about the UF_COMPRESSED flag, I'm surprised that the files didn't become damaged. In any case, it would be interesting to try a restore while booted from the Snow Leopard disc, since Snow Leopard's version of disktool is more likely to be aware of the new compression features (if it's not, this will be a good bug report to send to Apple).
