Are "disk images" disk images or not?

I have seen the question "What are disk images" answered numerous times
with the assurance that they are exact sector-by-sector copies of real
physical disks. But my own eyes seem to contradict that apparently
standard answer.

Disregarding the instant .dmg "images" which can be cobbled together in
folders on the desktop, and concentrating on sincere attempts to create
real images of real physical disks with Disk Utility, if .dmg's are real
sector-by-sector copies, how come they shrink in size when files are
deleted from their source-devices to make the "images" fit on dvd ?

Can Disk Utility make, or is it even claiming to make, real images of
real physical disks?

Does anyone actually know?

 

There are many forms of disk images. Some are the standard sector by sector
copy of the entire disk. Some are a virtual disk, which can grow or shrink
as files are moved.

Then just to really complicate things, a disk image can be compressed and or
encrypted.

All can be read and created with the various incarnations of the OSX Disk
Utility, which at one time was two different programs and most have the file
type .dmg.

The CD(DVD) ROM images used for burning disks have the file type .cdr.

There are various utilities for reading .dmg files on other platforms, some
are more successful than others.

Geoff.

 

From your description of what you think a "real" image is, if you want
to make one then just use dd(1).

Disk Utility can be used to package a directory into a .dmg file that
can then be mounted as if it were a disk. As I understand it there is no
claim that it makes anything like what you are calling a "real" image.

I look forward to reading other responses - I might be surprised.

Ian

 

It doesn't make sector-perfect copies and doesn't claim to. There's also
virtually no need to for a mainstream user.

 

Physical copy of a disk can be of tremendous use when you have a failing
disk and you are willing to accept loss of already damaged sectors in
order to salvage the rest before the disk completely dies.

You can then use tools on your copy to try to fix broken structures to
recover files.

One way to test if the .dmg creators are able to make physical copies is
to load a CD whose structure is unknown to OS-X. (for instance , a VMS
CD). I should try this later on to see if it can be done.

If OS-X is able to make an image it would mean that it would be a
physical image since OS-X would not understand the file structure.

 

Thanks to everyone for the replies. I am now satisfied Disk Utility
isn't claiming to make sector-by-sector copies of disks according to
current use of the terminology.

Maybe it's a case of the meaning of "disk copy" evolving into something
different without a corresponding adjustment to the terminology. As GSM
pointed out, Disk Utility is a merger of two formerly different
utilities. One of those, I believe, was "Disk Copy". I understood
"diskcopy" and "filecopy" were two distinct concepts. Perhaps the
earlier need to distinguish is no longer relevant.

Or maybe frequent reference to .dmgs as "images" refers to the way it is
deposited on a CDROM track? I'm not sure if that is the case either.

Failing either of those explanations, the almost universal use of the
word "image" in describing .dmg files would appear to be a mystery.

 

Trying the opposite with highly suspect results is what led to my
initial question.

I used Disk Utility to make a compressed .dmg of an OSX-unmountable ext3
partition containing over a gigabyte of data. The resulting .dmg was
only 8 MB, casting serious doubt on my former assumption that .dmg's
were images of disk partitions regardless of their contents.

 

Is this what the "image" in .img and .dmg refers to? The DVD or CDROM
track it sometimes ends up as?

 

Is this what the "image" in .img and .dmg refers to? The DVD or CDROM
track it sometimes ends up as?[/QUOTE]

It has nothing to do with a DVD or CD ROM.

 

When a .dmg file in mounted, it is essentially indistinguishable from a
"real" disk and the term "image" seems quite appropriate.

 

To me as well. I don't see "image" as necessarily implying an exact copy
of the underlying structure. After all, a photographic image is not an
exact copy of the photographic subject; it just has a simillar
appearance when you look at it with your eyes. Likewise, a disk image
has the same appearance as a disk when you look at it through the file
system. If you look beyond the surface, it will certainly differ at some
level (for sure at the physical level, and likely at quite a bit higher
level as well), just like an image of a beautiful woman differs a lot
from a real woman beneath the surface (and for that matter, the
resemblance even fails rather poorly as soon as you get to the surface).

 

Just tried.

Inserted a VMS CD (hi-sierra format). OS-X tells me it doesn't know
this, so I "ignore" instead of "eject".

Disk Utility calls the disk disk0s1 or something like that.

It allows me to click on "restore", but does not let me drag it to the
"source" field.

Also, when you create a .dmg file with disk utility, it forces you to
specify a valid format mountable by OS-X.

This would mean that the disk utility would not have the ability to do
raw disk copy (physical sectors) as it insists on understanding the file
structure of both source and destination.


I assume that there is some unix utility that can do raw
sector-by-sector copy.

 

You're right: It has to differ, and that's what's confusing. Think about the
meaning of "exact image" as it relates to, say, a common CD or even a simple
Mac volume. You can't take the first bit (and I mean bit as in byte) of data
and start merrily writing away on your hard drive, copying the exact data
bit-for-bit -- you must at least have a wrapper around it or at least
introduce what it is to the operating system or it will be total garbage.

 

Actually, the container file itself can be an exact bit by bit copy of
the original drive. You can set file attributes (such as the file
extemsion) to invoke some handler that will mount this file as a disk
and use appropriate drivers.

I have used this on VMS. Did a physical backup of a corrupt drive to a
container file, and then used the disk image driver (LDdrive) to create
a disk device which I could then play with without touching the originla
drive. WIth a physical copy, you have access to blocks that are marked
"free" due to files being deleted by mistake for instance, and you can
use tools to recover it.

With a "logical" disk image (as disk utility does), it will not copy
blocks it considers unused into the container file and will recreate a
totally new drive which will *look* the same to you even thought it
won't be the same deep down.


With a physical copy, then a file in the reative boocks 1000 to 2000 on
the disk will be in relative blocks 1000 to 2000 on the container file.

With a logical image copy, files will not be in the same location in the
container fiel as they were in the original disk.

 

OK, I just whipped a VMS documentation CD off the shelf...

On inserting it, I get a message that it's an unrecognizable format and
a prompt to Ignore or Eject - this depends on the user settings in
System Preferences. IIRC the defaults supplied by OS X will simply
eject the disk straight away.

Next I fired up Disk Utility and could see the disk as "Untitled 0".
Right clicking on the disk and selecting "Information" gives me:

Disk Identifier : disk2s0

and then I can enter the following command to copy it.

sudo dd if=/dev/disk2s0 of=~/vmsdisk.iso

I think that's the correct incantation, it gives the correct sized
output (as reported by Disk Utility) file of 629.9 MB

Another way to look at the CD is:

diskutil list

/dev/disk2
#: type name size identifier
0: CD_partition_scheme *723.4 MB disk2
1: CD_ROM_Mode_1 629.9 MB disk2s0


Hmm... Out of curiosity I repeated the above dd command, but using
/dev/disk2 and it gave me an output file of 723.4 MB. I'm not sure
which one I should use for transferring to another system for reading. I
may risk creating a coaster or two later on to see what happens.

 

Of course there is If you want to copy /dev/rdisk1 to /dev/rdisk2
(assuming they are identical drives with a sector size of N bytes) you
would just do:

dd -bs=N if=/dev/rdisk1 of=/dev/rdisk2

Or you could just copy /dev/rdisk1 to a file on /dev/rdisk0 (assuming it
has enough space to hold it):

dd -bs=N if=/dev/rdisk1 of=IMAGEFILE

IMAGEFILE would then be an exact image of /dev/rdisk1 which you could
examine with any tools want, or copy later onto another identical disk:

dd -bs=N if=IMAGEFILE of=/dev/rdisk2

Ian

 

Paul,

Why not transfer your vmsimage.iso (BTW, that's a UniCode CD format
on the VMS CDs and not ISO 9660) and then, use LD (the virtual disk
driver) to connect to that file. Then, $ MOUNT/OVERRIDE=IDENT LDAn:
If your 'dd' copy is made from the appropriate device view of your
CD, it *should* mount on VMS; thus, proving out whether or not your
image will generate coasters or not when you burn them to media.

$ LD CONNECT vmsimage.iso LDA10:
$ MOUNT/OVERRIDE=IDENT LDA10:

--
VAXman- A Bored Certified VMS Kernel Mode Hacker VAXman(at)TMESIS(dot)ORG

http://www.quirkfactory.com/popart/asskey/eqn2.png

"Well my son, life is like a beanstalk, isn't it?"

 

Well... now I'm a bit curious...

First of all, Disk Utility has some hidden settings. You can probably
trigger them in the terminal, but an easy way is to get Onyx, go to
"Parameters > Other" and enable "show more disk formats" for Disk Utility.
(the exact titles may be different in English, I'm guessing right now, based
on my localized version).

Once you enabled this, Disk Utility will hugely enhance the "format" popup
in the save-dialog, including an option "copy whole drive".

I was always assuming that this exactly would/should result in a complete
block-by-block copy of the entire drive content.

 

Addendum...

If you don't want to download/use Onyx for that single task, you can also
simply double-click com.apple.DiskUtility.plist in your Library >
Preferences.

The first entry is "root > advanced-image-options" and you can just set it
from "no" to "yes".

 

Not the "container" -- the contents in it, yes, but not the container itself.
I guarantee that you didn't just start at the first block of corrupt drive
and start writing it to another disk at some particular block. Well, you DID,
but you're writing it sort of "inside" the container that defines it as a
certain kind of object.