Talk:Apple Disk Image

This article is rated C-class on Wikipedia's content assessment scale. It is of interest to the following WikiProjects:

Apple Inc. Mid‑importance This article is within the scope of WikiProject Apple Inc., a collaborative effort to improve the coverage of Apple, Mac, iOS and related topics on Wikipedia. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks.Apple Inc.Wikipedia:WikiProject Apple Inc.Template:WikiProject Apple Inc.Apple Inc. articles Mid This article has been rated as Mid-importance on the project's importance scale.

Bold text== Incompatibilities in dmg introduced across Mac OS X 10.1-5 generations == Someone knowledgable needs to add the unpleasant reality of how a dmg created on Intel-Mac fails to mount on 10.1 and 10.2 systems, unless steps are taken to ensure that it does, which gets neglected routinely these days.

For the disk to be mountable on 10.1 and 10.2, it needs to be generated with the hdiutil -fs HFS+ command, switch and argument -- when creating the image on the Intel-Mac.

Else, the 10.2 system, for example, will not be able to mount it, displaying the puzzling catch-all "Error 95" to the user, which is also caused the image was not completely downloaded or got corrupted.

But the real problem is systematic -- the disk's "magic" went unrecognized.

When attepting to mount (attach) such a disk on a 10.2 from command line, say:

hdiutil attach -verbose o950s_4844.dmg (not to pick on Opera, but hey...) you will get output revealing why the disk won't mount, while, in this case, you will be presented in the middle of things with a licence agreement, and if you say Y, it still won't mount. Here's a capture of the whole thing:

marek@[~/Desktop] 69: /usr/bin/hdiutil attach -verbose o950s_4844.dmg 
hdiutil attach: DILoadDriver: checking for disk image driver

DI_kextExists: cannot find IOHDIXController object
hdiutil attach: DILoadDriver: DI_kextExists() returned 0xE00002C0 (-536870208)

hdiutil attach: DILoadDriver: loading disk image driver

hdiutil attach: DILoadDriver: checking again for disk image driver

hdiutil attach: DILoadDriver: DI_kextExists() returned 0x00000000 (0)

DIBackingStoreInstantiatorProbe: interface  0, score      100, CBSDBackingStore
DIBackingStoreInstantiatorProbe: interface  1, score    -1000, CHTTPBackingStore
DIBackingStoreInstantiatorProbe: interface  2, score    -1000, CRAMBackingStore
DIBackingStoreInstantiatorProbe: interface  3, score      100, CCarbonBackingStore
DIBackingStoreInstantiatorProbe: interface  4, score    -1000, CDevBackingStore
DIBackingStoreInstantiatorProbe: interface  5, score    -1000, CCURLBackingStore
DIBackingStoreInstantiatorProbe: selecting CBSDBackingStore
DIFileEncodingInstantiatorProbe: interface  0, score    -1000, CMacBinaryEncoding
DIFileEncodingInstantiatorProbe: interface  1, score    -1000, CAppleSingleEncoding
DIFileEncodingInstantiatorProbe: interface  2, score    -1000, CEncryptedEncoding
DIFileEncodingInstantiatorProbe: nothing to select.
DIFileEncodingInstantiatorProbe: interface  0, score      900, CUDIFEncoding
DIFileEncodingInstantiatorProbe: selecting CUDIFEncoding
DIFileEncodingNewWithBackingStore: CUDIFEncoding
hdiutil attach: DIFileEncodingNewWithBackingStore: instantiator returned 0

DIFileEncodingInstantiatorProbe: interface  0, score    -1000, CSegmentedNDIFEncoding
DIFileEncodingInstantiatorProbe: interface  1, score    -1000, CSegmentedUDIFEncoding
DIFileEncodingInstantiatorProbe: interface  2, score    -1000, CSegmentedUDIFRawEncoding
DIFileEncodingInstantiatorProbe: nothing to select.
DIDiskImageInstantiatorProbe: interface  0, score        0, CDARTDiskImage
DIDiskImageInstantiatorProbe: interface  1, score        0, CDiskCopy42DiskImage
DIDiskImageInstantiatorProbe: interface  2, score    -1000, CNDIFDiskImage
DIDiskImageInstantiatorProbe: interface  3, score     1000, CUDIFDiskImage
DIDiskImageInstantiatorProbe: interface  4, score    -1000, CRawDiskImage
DIDiskImageInstantiatorProbe: interface  5, score     -100, CShadowedDiskImage
DIDiskImageInstantiatorProbe: interface  6, score        0, CSparseDiskImage
DIDiskImageInstantiatorProbe: interface  7, score    -1000, CCFPlugInDiskImage
DIDiskImageInstantiatorProbe: selecting CUDIFDiskImage
DIDiskImageNewWithBackingStore: CUDIFDiskImage
hdiutil attach: DIDiskImageNewWithBackingStore: instantiator returned 0

Opera Browser Information: LICENSE.TXT
=========================================== Copyright (C) Opera
Software 1995-2008

<snip>

Contact us:  <http://www.opera.com/contact/>

Agree Y/N? y
hdiutil attach: mounting "o950s_4844.dmg" failed: no mountable file systems.
marek@[~/Desktop] 70: 

--216.80.74.216 (talk) 21:31, 31 May 2008 (UTC)[reply]

Reminds me of the history of ms windows msbackup, qic, ntbackup, etc. at most extreme, a win98 patch destroyed ability to restore archives. 2z2z (talk) 17:06, 17 November 2008 (UTC)[reply]

Beyond nomenclature, in what way is this file format a disk image? It sounds more like an archiving format along the lines of zip/rar. Ham Pastrami (talk) 13:54, 24 July 2008 (UTC)[reply]

Disk images are in essence archive formats with the goal to replicate a file system structure or sector layout accurately. Standard archive format on the other hand only cares about the files with emphasize on reducing size and maintaining compatibility, etc. --Voidvector (talk) 20:26, 24 September 2008 (UTC)[reply]

from googling, seems dmg may optionally be compressed or encrypted, adding complications to work with dmg. Bootable dmg is a whole 'nother headache. 2z2z (talk) 16:59, 17 November 2008 (UTC)[reply]

encryption is a whole another matter but I suspect the formats (except the very old ADC) are very standard, it should be trivial to uncompress a bz2/gzip compressed disk image. If you run BSD/Linux "file" command on them, it sees them as bz2 or gz compressed data. Ilgaz (talk) 21:53, 30 April 2009 (UTC)[reply]

.dmg format images are disk images in that they contain arbitrary block data, which can be directly mapped as a block device through proper drivers. There is no restriction on what kind of file system / partition system you put on a .dmg image, although HFS+ wrapped in an Apple Partition Map is the most common configuration. You can also put CD images with ISO9660 file systems inside .dmgs. --Unsound (talk) 10:23, 30 November 2008 (UTC)[reply]

It is absolutely a disk image, down to the partition map and in fact OS X (hdiutil) can image disks that it can't read at all (because it has no clue about fs) and effectively restore them. Of course, it is not recommended. For example "over the network" time machine backups are actually disk images having their very own partition map and even journal. One can also defragment large disk images or perform maintenance on them with regular tools, just like a real disk. Ilgaz (talk) 21:50, 30 April 2009 (UTC)[reply]

btw, dmg2iso binary is either inoperative or usually buggy on win (xp at least). 2z2z (talk) 16:57, 17 November 2008 (UTC)[reply]

I can recommend DMGExtractor, a free software Java utility that I wrote by studying dmg2iso and trying to correct bugs in it. It has evolved a lot since then and should handle most .dmg disk images (though not the rare UDCO type, using an Apple proprietary compression algorithm). --Unsound (talk) 10:27, 30 November 2008 (UTC)[reply]

i wonder if this method is "obsolete" in that UI can now make Dmg from folder? 2002 post with similar goal: http://www.macosxhints.com/article.php?story=20020311215452999 2z2z (talk) 17:24, 17 November 2008 (UTC)[reply]

for a long time, at least since OS X 10.3.x, Disk Utility (in /Applications/Utilities) can make images from folders, with GUI available in "File"-->"New"--->"Image from Folder" menu of tool. Ilgaz (talk) 22:03, 30 April 2009 (UTC)[reply]

I see the article mentions disk image format as something "secret", e.g. hidden specs and I wonder if it is really the case? I have heard similar claims about HFS+ (and journaled variant) and yet we have commercial vendors releasing sector level defragmenter, open source developers releasing "HFS Debug" type utilities and I am not sure they spent any time to "hack" the format rather than reading the official documentation and open source site of Apple.

Are we absolutely sure it is proprietary or perhaps the foreign systems such as Windows live their own (core level) issues with DMG files such as having no free HFS+ reader and not being able to read the actual filesystem itself properly?

It looks like someone was really wanting to use the term proprietary on an Apple article to me.

Even if it evolves (indeed it does, with each major OS update), as long as changes documented by Apple, one can't call it propertiary. Ilgaz (talk) 22:15, 30 April 2009 (UTC)[reply]

Apple Disk Image files are published with a MIME type of application/x-apple-diskimage. Many (

Major problems with this whole paragraph. Can it be rewritten with due regard to our needs to have references and no synthesis? I can't do it, I don't know the subject matter well. User:Pedant (talk) 03:32, 12 June 2010 (UTC)[reply]

I also have problems here. I own a Mac for some years now, and I've never found a DMG distributed inside a bzip2 or ZIP archive. I also never had problems with DMGs downloading as text. So I think this is simply not true. Or not true any more perhaps. —Preceding unsigned comment added by 81.204.1.136 (talk) 15:00, 27 January 2011 (UTC)[reply]

This issue was fairly common in the early 2000s. (One prominent example I recall was the download page for Camino.) Modern distributions of Apache come with the correct MIME mapping for .DMG, so it's no longer much of an issue. Modern browsers may 'sniff' filetypes as well. At this point it's a very obscure tech support issue and not worth mentioning in the article.Atarivideomusic (talk) 06:09, 26 February 2012 (UTC)[reply]

The document says:

Currently, the only way to open a Disk Image in Mac OS 9 is to use either the developer version of Disk Copy (version 6.4), or a beta version of the unreleased 6.5. However, both versions can only open uncompressed images; compressed Disk Images are unusable on Mac OS 9.^{[original research?]}

About the original research annotation, at least, I can confirm the same. I played with MacOS9 in a virtual machine two years ago, and faced the same story. This is not an allegation, this is a fact. --Hibou57 (talk) 10:29, 14 November 2011 (UTC)[reply]

@Hibou57. Hi, not it is NOT a fact that Mac OS cannot read compressed .dmgs .dmg files are compressed by default. In fact if you try to convert one, i.e. to an .iso or extract raw data,...you will see what I mean. The "official" nonsense out there is for a reason. The truth on Wikipedia is for another reason. ...cheers. ____Ἑλλαιβάριος Ellaivarios____ 02:52, 23 February 2012 (UTC)[reply]

Firstly, the article says that .dmg supports file compression, but does not say at what ratio. We should naturally assume that the file compression type is lossless, akin to .rar or .zip. Based on my own experience, I reckon that the file compression ratio of a standard .dmg would be approximately 0.365%. That means that if you have a file which is reported by your file system to be about 500MB, for instance, and you turn it into a dmg image, your file system should report it to have a file size of approximately 182.5MB. This is actually amazing. However, I have no source to back it up as it is derived entirely from my own empirical knowledge, which is why I have not posted it in the article. If anyone has the official source for this, please do post it and update the article as necessary. In any case, this is probably the best compression around, more than the highest .zip and .rar compression I think, correctly if I am wrong.

Secondly, the article says that .dmg supports password compression, but does not say anything about the algorithm and/or method or the bit level. Wouold it be unwise to assume it is 128-bit encryption? I have no idea on this matter. Anyone who can confirm this should update the article accordingly as well.

cheers

____Ἑλλαιβάριος Ellaivarios____ 02:49, 23 February 2012 (UTC)[reply]

ROTFL! Of course all the compression is lossless, and the compression ratio is both data-dependent and algorithm-dependent! See data compression!

The hdiutil man page (on MacOS) mentions (with #added notes from me) some of the disk image formats it supports:

                     UDRW - UDIF read/write image
                     UDRO - UDIF read-only image
                     UDCO - UDIF ADC-compressed image (which carefully optimizes for fast decompression according to the man page)
                     UDZO - UDIF zlib-compressed image
                     UDBZ - UDIF [bzip2]]-compressed image (OS X 10.4+ only) (#well-known for high compression ratios and slow compression)
                     UFBI - UDIF entire image with MD5 checksum
                     UDRo - UDIF read-only (obsolete format)
                     UDCo - UDIF compressed (obsolete format)
                     UDTO - DVD/CD-R master for export
                     UDxx - UDIF stub image
                     UDSP - SPARSE (grows with content)
                     UDSB - SPARSEBUNDLE (grows with content; bundle-backed)
                     RdWr - NDIF read/write image (deprecated)
                     Rdxx - NDIF read-only image (Disk Copy 6.3.3 format)
                     ROCo - NDIF compressed image (deprecated)
                     Rken - NDIF compressed (obsolete format)  #KenCode is a closed format, which a coder claims had (in PPC days) a "compression ratio is as good as commercial Macintosh compressors with .. extremely fast Decompression. [1]
                     DC42 - Disk Copy 4.2 image

If someone did some competent benchmark testing and blogged about it, the blog post would IMO qualify as a

HFS+ (since 10.5) but it would be cool to hear if, e.g. applications run (or files read) faster or slower from an ADC-comprssed, bzip2-compressed or KenCode-compressed disk image compared to transparently compressed files on a raw HFS+ filesystem, as well as how disk usage compares. (The benchmarking would have to be done carefully, controlling for things like caching, double compression (wouldn't want the app files inside a compressed disk image to themselves be compressed, as that would slow things down), and access-time updates.) I would expect some apps run fastest from ADC or bzip2'd disk images. I would guess that transparent compression will outperform the rest where a significant fraction of the files are already compressed, as it avoids redundant compression. I was unable to find such benchmark results with a little googling. --Elvey (talk) 20:30, 12 March 2012 (UTC)[reply

]

I just transparently compressed my /Applications folder. Now I can fit more on my SSD; /Applications shrunk by 5GB!--Elvey (talk) 20:30, 12 March 2012 (UTC)[reply]

Hello,

Recent disk images, like the InstallESD.dmg used to install Mac OS X Lion, do not comply anymore with the file format described in this article, but are xar archives.

I hope that helps, --MathsPoetry (talk) 08:30, 20 April 2012 (UTC)[reply]

Actually, they aren't xar, but new 'koly' format which also uses xml info. — Preceding unsigned comment added by 91.77.146.100 (talk) 11:54, 10 June 2014 (UTC)[reply]

The article says: "In Linux and possibly other Unix flavors, most .dmg files can be burned to CD/DVD using any CD-burner program (using cdrecord directly or a front-end such as K3B or Brasero) or directly mounted to a mountpoint (e.g. mount -o loop,ro -t hfsplus imagefile.dmg /mnt/mountpoint)."

This is simply not true. The Linux kernel only supports HFS+ in this manner, not DMG with embedded HFS+. There are some files with .dmg file extension which are just plain HFS+ filesystems, but that's simply not a real DMG file as described in the article!

LubosD (talk) 20:49, 29 March 2015 (UTC)[reply]

Just fix it, if somebody has better info than you they can revert and add a reference. –Be..anyone (talk) 07:56, 30 March 2015 (UTC)[reply]

As I haven't really found anything pertinent on the web - although I know it does not really pertain to this article - I'll ask anyway: any information about how/why a .dmg file download on a Windows PC has been (automatically, ...?) renamed to .man? Sorry for asking this here, if you know a better place to ask, please redirect me. --Alien4 (talk) 16:38, 4 January 2017 (UTC)[reply]