What's the difference between .img and .dmg disk images?
They are similar, and you can use either with Mac OS X.
One difference is .dmg disk images can be formatted in one of these formats:
-Mac OS Extended (HFS Plus) ***
-Mac OS Extended Journaled
-Mac OS Standard (HFS) ***
-UFS
-MS-DOS ***
While .img disk images can be formatted as:
-Mac OS Extended (HFS Plus) ***
-Mac OS Standard (HFS) ***
-MS-DOS ***
-ProDOS
-Universal Disk Format.
*** denotes fileformat that is in both .img + .dmg standards!
original article here -- http://support.apple.com/kb/ht1611
types of disk image formatsoriginal article -- http://support.apple.com/kb/PH5866
read/write Choose this if you want to continue adding files to the disk image after it’s created. sparse bundle disk image Choose this if you want to continue adding files to the image and want to conserve space. The disk image is just large enough to hold the files in it and expands to its maximum size as you add files to it. For example, if you create a 100 MB sparse bundle disk image, its maximum size is 100 MB. (This format replaces sparse disk image.) read-only Choose this If you don’t need to add more files to the disk image. compressed Choose this if you don’t need to add more files to the image and want to conserve space. The data is compressed, so the disk image is smaller than the original data. CD/DVD master Choose this if you want to use the disk image with a third-party application. The disk image contains a copy of all sectors of the disk, whether they’re used or not, and copies them to other CDs or DVDs exactly as they’re stored in the disk image.
what is a .img file?
A Macintosh disk image file is a mirror copy of the Mac file system and can be mounted on a computer as a virtual hard disk drive. These Macintosh disk image files can also be used as virtual optical drives like DVD and CD drives. Mac OS 9 and older versions are integrated with support for using and mounting these Macintosh disk image files. These Macintosh disk image files are saved in the IMG format and are affixed with the .img extension. These IMG files are also stored with encoding specifications and implemented with file compression standards proprietary to Apple. Similar to ISO files, an IMG file can sometimes be changed to an ISO file by simply replacing the .img extension with the .iso extension, and doing this will allow a user to use the IMG file with an image mounting program developed for Microsoft Windows-based systems. Mac OS X is also implemented with support for opening and using these IMG files, though newer disk image file formats are now widely used by associated applications programmed for Mac platforms.
original article -- http://www.reviversoft.com/file-extensions/img
Quote**** updated findings
testing this on the freshdraginstall diskcopy readonly/compressed (under 9) yielded a file with the size: 504mb
and using stuffit to create a .sitx (under x)
so while using stuffit under x to create .sitx gave a faster compression time + a slightly smaller size
this file will always require stuffit (and X) to expand whereas the diskcopy compression is natively supported and only slightly larger
but it did take alot longer to compress!! but this file is also natively compatible within both 9 + X and like i said only slightly larger
heres a quick link to a thread talking about self extracting "sitX" files.. (or the lack therof!)
q: Why doesn't Stuffit support the creation of self-extracting SITX files? Surely this isn't that hard to implement? (I could be wrong of course!)
a: this functionality is coming, but I can't give you a definite ETA of when it will be in the product.
this communication is from june 2003...
original article -- http://webcache.googleusercontent.com/search?q=cache:aiREgPS_9s0J:archive.macfixitforums.com/ubbthreads.php/topics/101236/Self_extracting_SITX_files+&cd=2&hl=en&ct=clnk&gl=ca&client=firefox-a
Disk Images, DiskCopy, and ShrinkWrap
Years ago, Apple had a problem. It wanted to distribute software via the
Internet. But some of the software it wanted to distribute, such as its
PlainTalk Speech kit, wasn’t just a single control panel; it was a suite of files
— extensions, control panels, and so on — that had to be placed into the right
spots in your System folder. To ensure that all these pieces would go into the
right places, Apple also needed an Installer program. How on earth could
Apple distribute all of these pieces electronically — while still keeping them
together, with an installer, in an arrangement the installer understood?
The solution: Apple created disk images. A disk image (a file whose name
generally ends with the suffix .img) is an increasingly common file format for
downloaded software, especially from Apple. But once you’ve downloaded an
.img file to your hard drive, you can’t do a thing with it — unless you have a
program that can open it.
In this case, the program you need is DiskDup + (shareware), Disk Copy or
Disk Image Mounter (from Apple, available from its Web site) — or the much
superior ShrinkWrap (from Aladdin, and included with this book).
Here’s how you work ShrinkWrap: Whenever you encounter an
.img file — including the Disk Tools floppy-disk “images” that come on the Mac OS 8.5
CD-ROMs — double-click it (if you have Disk Copy) or drag it onto
ShrinkWrap’s icon. That’s it; a “virtual floppy-disk” icon appears on your
screen, exactly as though it’s a real floppy disk (the lower-right icon in Figure
22-7). Double-click it to see what Apple has in store for you — an installer, a
Disk Tools floppy’s contents, or whatever. When you’re finished using the
mounted disk image, drag its icon (not the original .img file!) to the Trash
You can also create a disk image. Why would you want to do so? Maybe you,
like Apple, want to distribute something (a little presentation, for example)
to friends, confident that all pieces will remain in their original folder
configurations. Maybe you haven’t switched to the HFS Plus hard drive-
formatting scheme (see Chapter 8), and you realize that a lot of small files
won’t waste their usual 64K apiece if they’re all stored together on a much
smaller “virtual disk.” (That last sentence will make a lot more sense once
you’ve read Chapter 8.)
Anyway, to create a disk image of your own, just drag a disk or folder onto
ShrinkWrap’s icon. The new .img file is created automatically. (You’re not
limited to creating disk images of floppies, by the way. ShrinkWrap is perfectly
happy to create disk images of entire hard drives, Zip disks, Jaz cartridges, or
whatever; it even offers to compress the contents in the process. As thousands
of teenage software pirates have discovered, that feature makes ShrinkWrap
ideal for creating easily uploaded duplicates of entire CD-ROMs.) LOL!
No ShrinkWrap needed — and passwords
ShrinkWrap’s Preferences are worth checking out. Among our favorite features,
for example, is a self-mounting option. It lets you create disk-image files that your friends can open even
if they don’t have Disk Copy, ShrinkWrap, or a similar
program. A self-mounting disk image is just as user-friendly as, say, a self-
extracting archive, as described earlier in this chapter — just double-click to
mount the “virtual disk” on the screen.
Another great preference: You can opt to protect an archive with a password.
Yes, all you Mac fans who’ve e-mailed us with this question — now you can
protect specific folders on your hard drive from prying eyes. (Remember the
password, though. There’s no “back door” to ShrinkWrap.
- Chronology Of StuffIt
Here is the progression of the StuffIt Archive format over time. It might prove helpful in understanding the evolution of various archives you may encounter.
1993 -- Introduction of the StuffIt 3 archive format (used .sit extension) -- Better compression compared to original StuffIt archive format.
1998 -- Introduction of the StuffIt 5 archive format (used .sit extension) -- Again, improved compression over prior version. This version of StuffIt also removed some of the dependencies on resource fork data to enable better cross platform support sending files between Mac and PC.
2002 -- Introduction of the StuffIt X file format. (used .sitx extension) -- Better compression, strong encryption up to 512-bit, increased the number of files allowed in a single archive, increased the maximum allowable archive size.
2005 -- An updated to the StuffIt X file format added compression of JPEG images –- able to compress JPEGs by an additional 20 to 30 percent without further reductions to image quality.
2007 – An update to the StuffIt X file format added compression of the Microsoft Office 2007 file format (introduced in Office 2008 on the Mac). These new document formats (.docx, .xlsx, .pptx) are essentially compressed with Zip compression by the Microsoft applications, so the Finder’s zip compression is unable to make them smaller. StuffIt introduced a new technique that allowed Office 2007/8 documents to be further compressed, and for inline JPEGs stored in these documents to be compressed using the JPEG compression method introduced in 2005.
2008 – An update to the StuffIt X file format added support for specialized compression of 24-bit images – TIFFs, PNGs, Bitmaps, etc. Also added was improved compression of PDF and MP3 files.
-- Progression of File Type and Creator
StuffIt 1.5.1
Extension: .sit
Type: SIT!
Creator: SIT!
StuffIt 2 (released with StuffIt Deluxe 3.0)
Extension: .sit
Type: SITD
Creator: SIT!
StuffIt 5 (released with StuffIt Deluxe 5.0)
Extension: .sit
Type: SIT5
Creator: SIT!
StuffIt X 7.0 (Released with StuffIt Deluxe 7.0 – this is the newer StuffIt X file format.
Extension: .sitx
Type: SITX
Creator: SIT
This information could come in handy if, somehow, the type or creator of an archive has been altered or corrupted. It might be possible to change that file data and achieve a successful unstuff. There are a few apps plus command line tools and developer tools to change the file type and creator.
As a suggestion to Newbies, I strongly recommend, that after getting Mac OS 9 up and running, use OS 9 to extract and install anything that you download from our site... since all OS 9 DAW software is pretty useless when running OS 9 in classic mode anyway, stay in OS 9 to extract and install all apps (just ignore OS X altogether); this will avoid many of the issues discussed here. Our site has been geared to those in an OS 9 environment... period. So this whole image debate is a mute point
Chris, as far as cloning a hard drive and preserving authorized plugins... I gave up on that in 2008 with as much frustration as you are experiencing now... I am hoping you find something... it would benefit all of us... I do over 20 installs when stting up a new DAW.
image files do not need to be .bin´ed, as they are binary files.
- dmg does not work in OS9
- self mounting images should be avoided on the net because they execute code
it can under circumstances be wise to stuff or zip images files, namely when the image is a master, i.e. may not be changed in order to make it work from CD or DVD later. especially when using shrink wrap images it can easily happen that you change its content by accident.
The reason we "Mac Binary" encode toast images, even though they are "Binary already" is to encapsulate them so the the icon and creator is preserved in the resource fork... although the image remains intact without encoding... our initial tests with Adrive (the service we use) exposed that when a toast image file is not encoded, after downloading it does not have an icon and "newbies" may not know that they have to open toast first to burn or mount the file... even though we named most files .toast
Not Exactly true. There was the last disk utility from apple to OS9 that could mount some dmg files, but not all...
just to clear the confusion caused here a bit:
- dmg does not work in OS9
Not Exactly true. There was the last disk utility from apple to OS9 that could mount some dmg files, but not all...
just to clear the confusion caused here a bit:
- dmg does not work in OS9
Disk Description : Apple UDIF read-only Media
Total Capacity : 250.0 MB (262,144,000 Bytes)
Connection Bus : Disk Image
Disk Write Status : Read Only
http://en.wikipedia.org/wiki/Apple_Disk_Image#UDIF_data_format
Apple disk image files are essentially raw disk images (i.e. contain block data) with some added metadata, optionally with one or two layers applied that provide compression and encryption. In hdiutil these layers are called CUDIFEncoding and CEncryptedEncoding.[1]
UDIF supports ADC (an old proprietary compression format by Apple), zlib, and bzip2 (Mac OS X v10.4 and later only) compression internally.
dmg files can be opened by diskcopy 6.5b3 provided they meet a certain specific criteria.
for exactly that purpose and that purpose alone... to transport the filesystems of software installers over the internet
i really fail to understand where u are coming from with this.. of course it executes code it installs the app?
so does anything else u can put in a stuffit once u expand it?
when creating a shrinkwrap package there is a matrix of different settings
.zip is the LAST FORMAT you should ever use for mac os 9 files
Quote.zip is the LAST FORMAT you should ever use for mac os 9 files
it is a much work for me to boot into another OS (only to upload 2 mb) as it would be for the other side to boot into OSX to unzip a file.
the point i was making about dmg is that it is useless to know that dmg files using no compression can also be mounted in OS9, because dmg files are usually using compression. try downloading some OSX program off the net and opening them in OS9 and you will see what i mean.
IMG is for Mac OS 9. There's no other reason to use IMG these days.
hdiutil convert (dmgfilename).dmg -format Rdxx -o (imgfilename).imgthis code will convert a .dmg to a .img Do NOT add compression and make all DMG files R/W..
Do not use Toast 5 to image original audio App CDs... it does not copy hidden /unsed blocks like Toast 4.1 does
and why would u want to open a mac os x program in mac os 9? in most cases this would be useless.
So I would say that the only thing I can add (to all this great research you have done) is that Toast 4.1 is still the best utility to image all original Audio Application and Plugin CDs... I verified this many times... simply make a Cubase VST 5 CD image using any other version of Toast (even in X) or Disk Utility, and it will not authorize the install.
Legacy NDIF Disk ImageNDIF (.img) disk images are compatible with System 7, Mac OS 8–9, and Mac OS X. These can be useful for exchanging files with legacy Macs or for use with emulators such as Sheepshaver and Basilisk. NDIF disk image files use resource forks, so some care must be taken in transferring them over the Internet. They are also limited to 2 GB of logical size.
the entire point of this post was to urge the use of .img apple disk image files (NDIF)
BECAUSE they are compatible on all versions of OSX + almost all flavours of classic Mac OS (7.x, 8.x, 9.x)
This is a bit of a bump, but there appears to be a bit of misunderstanding in these threads as to what disk images are, unless I'm totally misreading people's statements.
Way way back, Apple created a disk image format (DiskDup+?). It took the contents of a 400 or 800Kb disk, and wrote it out to a file on a hard disk. This was the original Apple Disk Image format, and was in direct competition with third party formats on the Apple series computers like SHK (Shrinkit). The format included a wrapper that indicated the way the contents were formatted -- usually ProDOS, MFS or HFS. The contents themselves were ignored, and presented directly to the host operating system as a virtual device -- so the OS would be in charge of reading out the contents and either recognizing or not recognizing the format.
When 1.44MB disks came along, along with larger SCSI hard disks, Apple came up with a New Disk Image Format (referred to as NDIF).
NDIF was a bit smarter about how it encoded the disk data; it also included support for metadata and a disk checksum, supported arbitrary disk sizes, and had reserved space for future data use.
This reserved space came in handy, as it meant that new file system types (Joliet, High Sierra, UDF, HFS+ [all the various versions]) could be encoded with the container being able to present useful decoding information directly to the host process. So for the vast majority of "classic" Mac OS, NDIF images reigned supreme.
However, Toast came along with its own format for CD images; it was essentially the byte copy of the CD with a header on the front that included instructions on how to burn the data to the disc and append the index structure (because unlike HFS, optical disc formats write the index data at the end of the track, so that new tracks can be added to a write-only disc and the index information will still be up to date). NDIF can't dynamically support this index style.
Meanwhile, Shrinkwrap came along and chose another format, where the metadata was used to enable smart compression of the block data. This allowed for very accurate (and small) images of disks, but was not portable to different partition formats, and was not easily readable by other disk image tools.
When Apple introduced DMG-style disk images, they completely changed the container format: gone was the disk header with all the extra information; instead, this was all added to a footer, to make DMG files completely compatible with write-once-and-append read-only media. This means that starting with OS X DMGs, the actual partition data starts at byte 0, and you need to read the end of the file to find out the partition format. This can have some curious effects, especially when the first partition starts at block 0 with a ZIP file -- because the DMG then starts with a zip header, and the first file can actually be opened and manipulated by most zip applications.
Over the years, the partition formats Apple has supported in the OS have changed; first support for MFS was dropped, then support for HFS was dropped, then Apple dropped support for NDIF altogether in Disk Utility. It also stopped supporting some of the earlier esoteric versions of HFS+ as well.
Separate from all this, you've got the various optical media formats, some of which are supported by Apple, some of which aren't. ".iso" is *supposed* to refer to binary data in the ISO-9660 format, which can include HFS, High Sierra, Joliet, Red Book or even UDFv1 data. The data is written straight to file, with the track metadata being written to the end of the associated track (which can be in any of these formats).
".toast" images are essentially ISO-9660 images with a header on the front that includes instructions to Toast for how to handle the file beyond the track data included in-line.
"bin/cue" file pairs are the ISO-9660 compatible binary data paired with an external file that uses ASCII text to define the image's structure.
"img/cue/sub/ccd" file quartets are again the ISO-9660 compatible binary data paired with the external cue file, plus sub-track instructions for the burning software (to overcome some copy protection schemes) plus a "Clone CD" data file with the general instructions to tie all this together for the Windows software "Clone CD".
The big thing to notice here is that "Apple Disk Image" actually refers to three different container types, all of which support different combinations of partition layouts and formats, and are in turn supported by different combinations of Apple image tools and operating systems. You need to get the software, the operating system (with supported partition type) and the image format to all line up to be able to actually read/write/mount any given disk image.
Toast doesn't care about the partition type really, as long as it knows how to write it to disk. It passes actually mounting the partitions off to the host OS, which does the heavy lifting.