Hi, Peter.
1. You wrote:
"One, I'd like to know how to reliably open and convert my old archives and turn them into OSX .img or .dmg archives. Disk Utility is supposed to do this but in practice doesn't or does it in such an obtuse way as to render it useless."
It may be possible to either mount or convert your old Shrinkwrap .img and .smi files using
DropDMG. This utility, as far as I know, is essentially a GUI (graphical user interface) to the
hdiutil command in Terminal, which has support for some obsolete formats.
Disk Utility — again to the best of my knowledge as I do not have old Shrinkwrap files with which to test — won't deal with these files natively. While the disk image functions in Disk Utility are also provided by
hdiutil, Disk Utility only provides access, via is GUI, to a small subset of the functions in
hdiutil.
There is no Mac OS X version of Shrinkwrap and current versions of StuffIt Expander
do not support the .img or .smi formats. One must use an older version, e.g. StuffIt 7 — perhaps earlier — under Classic. Classic requires Mac OS 9.1,with version 9.2.2 recommended, especially under Tiger.
2. You wrote:
"what is the essential difference between .img and .dmg as well as .toast and out of all those which is most reliable and likely to be future proof as well as accessible from PC computers."
The original .img format is obsolete, as you've learned, though that extension is sometimes still used as an extension for disk images, which should properly carry the .dmg extension. The primary difference between .dmg and earlier formats is how resource forks are handled.
From what I can glean, the .toast disk image format is similar to the DVD/CD-R Master (.cdr) format. It's a disk image format created by Roxio Toast.
A brief history of Apple disk image formats can be found on
this page.
As to "future proof," who can say? If I could predict the future, I'd have won Lotto several times over by now. If you want to use disk images, stick with .dmg but pay attention to changes in Mac OS X when future versions are introduced. My gut feeling is that .dmg is fairly future-proof.
Cross-platform compatibility does
not come with disk images. That comes with archives, such as the UNIX .tar (Tape Archive) format, akin to .zip and StuffIt archives. The .tar archive has been around for ages. However, unlike disk images, archives must be unpacked: they don't simply mount.
The difficulties with disk images in a cross-platform environment comes from two facts:
• A disk image is a file that is, in essence, a virtual hard drive. Accordingly, when the disk image is created, it is written using a specific file system, i.e. a specification for how files are laid out on the disk. Macs and PCs use different — and generally incompatible — file systems:
• PCs running Windows do not read the Mac file systems "Mac OS Extended" (HFS+) or "Mac OS Extended (Journaled)" (HFS+J) without a third-party product like Mediafour's
MacDrive for Windows installed on the Windows PC.
• Likewise, Mac OS X can read the Windows NTFS file system, but not write to such disks.
• Mac OS X can read-from and write-to disks using the Windows FAT32 file system, aka MS-DOS format, but this creates other issues for PC users (primarily due to
Apple Double format) when PC users employ the disks on which Mac OS X users have saved files. Furthermore, Disk Utility under Tiger does not permit the creation of a disk image using the MS-DOS file system. Under Tiger, to create a disk image using the MS-DOS file system, one must either use
hdiutil or using a third-party utility that provides a GUI to
hdiutil.
• The disk images created on Macs are primarily for Macs. I've never tried mounting a disk image created on a Mac, even one using the MS-DOS file system, on a PC running windows.
When you create general disk images in Disk Utility, the disk image (.dmg) uses the "Mac OS Extended (Journaled)" file system, aka HFS+J. For information about file system journaling, see
Mac OS X: About File System Journaling.
Using HFS+J for all disk images created by Disk Utility — whether Read/Write or Read-Only disk images — is a design bug I've reported to Apple. This is a design bug since the disk's journal file cannot be updated on a Read-Only image. This results in Console messages that unnerve the uninitiated. Disk Utility should use "Mac OS Extended" (HFS+) for Read-Only images and make HFS+J optional for Read/Write images.
There is one additional concern with disk images: bad sectors on hard drives. While generally rare, hard drives can develop bad sectors at any time. If a bad sector develops in the space occupied by a file,that file is corrupted and the data in it is usually irrevocably lost. Disk images are files: if a bad sector develops in the space occupied by a disk image, that disk image is corrupted and generally will no longer mount. This means
all of the data in the disk image may be irrevocably lost. This is particularly true with encrypted disk images: bad sectors developing in the space occupied by an encrypted disk image means all the data in that encrypted disk image is lost. This is the "Achilles heel" of FileVault, which uses an encrypted, sparse disk image for one's Home folder.
While everyone should implement a comprehensive "Backup and Recovery" solution —
such as the one I use — to protect their investment in their priceless data, good backups are essential if you archive data in disk images.
Hope this helps.
Good luck!
😉 Dr. Smoke
Author:
Troubleshooting Mac® OS X
---
Note: The information provided in the link(s) above is freely available. However, because I own The X Lab™, a commercial Web site to which some of these links point, the Apple Discussions
Terms of Use require I include the following disclosure statement with this post:
I may receive some form of compensation, financial or otherwise, from my recommendation or link.
