Are "disk images" disk images or not?

Discussion in 'Apple' started by Tinkerer Atlarge, Jun 1, 2009.

  1. 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?
     
    Tinkerer Atlarge, Jun 1, 2009
    #1
    1. Advertisements

  2. 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.
     
    Geoffrey S. Mendelson, Jun 1, 2009
    #2
    1. Advertisements

  3. Tinkerer Atlarge

    Ian Gregory Guest

    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
     
    Ian Gregory, Jun 1, 2009
    #3
  4. It doesn't make sector-perfect copies and doesn't claim to. There's also
    virtually no need to for a mainstream user.
     
    Gregory Weston, Jun 1, 2009
    #4
  5. Tinkerer Atlarge

    JF Mezei Guest

    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.
     
    JF Mezei, Jun 1, 2009
    #5
  6. 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.
     
    Tinkerer Atlarge, Jun 2, 2009
    #6
  7. 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.
     
    Tinkerer Atlarge, Jun 2, 2009
    #7
  8. Is this what the "image" in .img and .dmg refers to? The DVD or CDROM
    track it sometimes ends up as?
     
    Tinkerer Atlarge, Jun 2, 2009
    #8
  9. 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.
     
    Michelle Steiner, Jun 2, 2009
    #9
  10. Tinkerer Atlarge

    Tom Stiller Guest

    When a .dmg file in mounted, it is essentially indistinguishable from a
    "real" disk and the term "image" seems quite appropriate.
     
    Tom Stiller, Jun 2, 2009
    #10
  11. 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).
     
    Richard Maine, Jun 2, 2009
    #11
  12. Tinkerer Atlarge

    JF Mezei Guest

    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.
     
    JF Mezei, Jun 2, 2009
    #12
  13. Tinkerer Atlarge

    Tim Murray Guest

    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.
     
    Tim Murray, Jun 2, 2009
    #13
  14. Tinkerer Atlarge

    JF Mezei Guest

    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.
     
    JF Mezei, Jun 2, 2009
    #14
  15. Tinkerer Atlarge

    P. Sture Guest

    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.
     
    P. Sture, Jun 2, 2009
    #15
  16. Tinkerer Atlarge

    Ian Gregory Guest

    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
     
    Ian Gregory, Jun 2, 2009
    #16
  17. Tinkerer Atlarge

    VAXman- Guest

    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?"
     
    VAXman- , Jun 2, 2009
    #17
  18. Tinkerer Atlarge

    MartinC Guest

    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.
     
    MartinC, Jun 2, 2009
    #18
  19. Tinkerer Atlarge

    MartinC Guest

    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".
     
    MartinC, Jun 2, 2009
    #19
  20. Tinkerer Atlarge

    Tim Murray Guest

    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.
     
    Tim Murray, Jun 2, 2009
    #20
    1. Advertisements

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.