Ok, very nice; now, can anyone explain what are all those immage options...
Thanks in advance

[ Reply to This | # ]

well by far the most useful of them to some will be the Disk Copy 4.2 image format. This means you can create disk images for OS 9 users without rebooting into OS 9. Very nice.

[ Reply to This | # ]

Disk Copy 4.2 was for images way earlier than OS 9. Now I can make images for my old System 6 disks... if I only had a 800k floppy drive to connect to my flat panel iMac...

[ Reply to This | # ]

Apple DiskCopy 4.2: very old uncompressed format, mostly useless now. Maybe very very old systems can't run DiskCopy 6 and would require that (provided you find the old DiskCopy 4 app, which didn't come with the system). At least System 7 and above can run the last DiskCopy 6 app.

NDIF: Apple DiskCopy 6. The best (can provide compression, mounts under X-9-8-7-...) In fact I still wonder why Apple needed the new dmg format which doesn't even provide better compression than NDIF (if dmg had the level of compression ShrinkWrap achieved using StuffIt Engine, then nobody would ever need "archive" formats like zip or sit, which require decompression before using their content). If the dmg compression level is variable, I would welcome any suggestion to easily tweak it (I think PathFinder gives such options).
NDIF read/write: it's in the name, uncompressed
NDIF read only: uncompressed but sized to the actual content
NDIF compressed: read-only and compressed, the archive format, ideal for storage and distribution of mac programs and data
NDIF compressed (KenCode): not sure, same as above with added CRC check?

The other formats are new .dmg images, which don't mount under OS 9 (some of those may mount using the unreleased DiskCopy 6.4 and 6.5b11 apps).

By the way, ShrinkWrap definitely left room for a killer shareware if someone was willing to write it: something that would manage dmg images better under OS X and 9, and other platforms while we're at it, would have the potential to replace the whole compressor/archive market, which is based on obsolete impractical concepts.

[ Reply to This | # ]

Thanks so much; btw, where did you get that info?

[ Reply to This | # ]

Mostly from the top of my head, where it got by trial and error I guess.

I spent some time a while back researching what disk image formats worked in what situations (there are MANY when you combine all the container / compression / encryption options you could get from legacy apps or ShrinkWrap).

And I've been trying to remember where I put the resulting chart ever since ;-)

[ Reply to This | # ]

I would recommend that everyone who is interested in this hint check out the man page of hdiutil (or if you don't like reading man pages, try http://osxfaq.com/man/1/hdiutil.ws , although you should probably get in the habit of checking out man pages and using man -k <keyword>)...

Use the 'hdiutil imageinfo <image_name>' command to check out the info on an image...
A good article on hdiutil can be found at: http://www.stepwise.com/Articles/Technical/2001-03-29.01.html


NDIF - New Disk Image Format
UDIF - Universal Disk Image Format

"...[The NDIF] file format comes in three flavors, Read/Write, Read-Only, and Read-Only Compressed, enabling the user to optimize the image file for flexibility, speed, or size. All NDIF flavors use industry standard CRC-32 checksums, and none waste space saving tag data.
Unfortunately, all the advantages of the NDIF format are offset by the fact that it presently only uses one compression scheme, an Apple proprietary codec named KenCode. Because of this restriction, no other commercial, shareware, or freeware utilities can legally read or write NDIF compressed image file formats without licensing the KenCode libraries from Apple. There have been overtures from Apple promising these libraries will be released to the general public at no charge, but I've seen no progress in this effort since November of 1995."
--from TidBITS #339


"UDRW UDIF read/write image
UFBI UDIF entire image with MD5 checksum
UDRO UDIF read/only image
UDCO UDIF ADC-compressed image
UDRo UDIF read/only (obsolete format)
UDCo UDIF compressed (obsolete format)
UDTO DVD/CD-R export image
UDxx UDIF stub image
UDZO UDIF zlib-compressed image
RdWr NDIF read/write image (deprecated)
Rdxx NDIF read/only image (deprecated, but still usable on OS 9 and OS X)
ROCo NDIF compressed image (deprecated)
Rken NDIF compressed (obsolete format)
DC42 Disk Copy 4.2 image"
--from hdiutil man page


"Unfortunately, Apple is very secretive and doesn't publish the format specifications. Apparently, they fear a degradation in user experience, were third parties allowed to write alternative utilities for handling disk images. Some older formats use proprietary compression algorithms, although the latest compressed format (UDZO) uses zlib. Mac OS X has a library (DiskImages.framework) that handles the various formats using a nice plug-in architecture, but it is marked private and neither headers nor documentation are available.
The "Disk Copy 4.2" format is the oldest one. It is quite straightforward (no sparse blocks, no compression) and Apple provides sample code to read it. However, the format is long obsolete and (to my knowledge) was only used for floppies.
The NDIF ("New Disk Image Format") format was introduced with Disk Copy 6.0. NDIF is a dual-fork format, meaning that all meta-data is stored in the resource fork. This makes them fragile for cross-system transport. Various variants of the format allow for sparse images (only actually used sectors are present), compression, and self-mounting images. Some more information on the introduction of NDIF is available in TidBITS #339.
Later, Apple introduced the UDIF format, which is basically the same as an NDIF, but in a robust single-fork format. Actually, it is simply the concatenation of the data fork, the resource fork, and a 512 byte header, without any padding."
--from a Google cached http://disktype.sourceforge.net/doc/ch03s13.html


"New Disk Image Format (NDIF) is used for storing dual forked files which are common with Mac OS 9 and given an extension of ".img". Universal Disk Image Format (UDIF) is used for storing single fork or flat files which are common for Mac OS X and given an extension of ".dmg". If your files contain resource forks, you'll need to use the NDIF(.img) format to preserve them. NDIF images cannot be gzipped since they contain resource forks. Gzipping will strip the resource fork and corrupt the image."
--from the docs for DMG Maker from Pliris Soft

[ Reply to This | # ]

that last part is wrong, you do NOT *NEED* NDIF to preserve resource forks, UDIF will preserve them.

---
Pell

[ Reply to This | # ]

It doesn't work for me. Does the Dev. Tool need to be installed first?

[ Reply to This | # ]

If it looks like it didn't work for you, make sure you look under the Utilities menu. The way the hint was worded, it sounded like it created a new top-level menu, when the Debug menu is really inside the Utilities menu. I thought it didn't work for me either until I started pulling the menus down.

John
http://homepage.mac.com/johnselvia/

---
Learn to count in binary on your fingers:
http://www.dnaco.net/~ivanjs/BINARY_FINGER_SW.html

[ Reply to This | # ]

Another way to do this is to add the following to com.apple.DiskCopy.plist with a text editor

<key>expert-mode</key>
<string>1</string>

The file is found in your preferences folder. If you haven't done this before, insert the lines at the end of the file, just before the following lines:

</dict>
</plist>

[ Reply to This | # ]

It doesn't work for me either!

I struggle at the best of times following this sites info, but I do undersand the UNIX logic behind what is typed in the terminal. What puzzles me, why would the Developer tool work and not the terminal?

I am just trying to improve what little understanding I have of this great system.

T.J. Hart

[ Reply to This | # ]

I tested this on my new laptop (12" G4, running 10.2.6), and it does NOT have the tools installed. It worked just fine. I'm not sure what's making for problems for some of you, but it has nothing to do with the Dev. Tools...

Good luck,
John-o

---

[ Reply to This | # ]

Screenshots and info here:

http://homepage.mac.com/squirrelgirl/PhotoAlbum16.html

[ Reply to This | # ]

I find it ironic. When OS X first came out, and people were disappointed with its responsiveness, a widespread urban legend arose that OS X was riddled with "debugging code" that slowed the system down. Now that we are over that, people are anxious to activate debugging code!

[ Reply to This | # ]

This does not activate debugging code. Recently Disk Copy lost some features it had in earlier releases of OS X. This restores some features, and adds others.

It looks like I can create rewriteable CD Master images again, which is a feature that I mtssed when it was removed/deactivated.

[ Reply to This | # ]

For those who don't want to fool with Terminal, here's an AppleScript script that will:

1. Add the setting (enabled) if it doesn't exist in the plist
2. Toggle the setting on subsequent executions

set write_ to "defaults write com.apple.diskcopy expert-mode "
try
	set currentMode to do shell script ¬
		"defaults read com.apple.diskcopy expert-mode"
on error e -- setting doesn't exist in plist - add and enable
	do shell script write_ & "1" -- Enable
	display dialog e
	return
end try

-- On subsequent runs, toggle the setting.
if currentMode is "0" then
	do shell script write_ & "1" -- Enable 
else
	do shell script write_ & "0" -- Disable
end if

[ Reply to This | # ]

I tried this hint on my PowerBook G4/500 OS 10.2.6 (german) and on a G4/400 with the same OS Version

I checked the plist with Terminal and plist Editor. In both cases the entries are as expected, but nothing changes in Diskcopy.

Why does this hint not work on my Macs ?

Galain

[ Reply to This | # ]

Hint works on my Macs, I thought that the changes would be visible as "Debug" menu entry but "Debug" is translated to german. The second thing: I expected to have the aballity to create DiskCopy 4.2 Images, instead of Mac OS X images, and didn´t know, that DiskCopy 4.2 is a very old format. The disk image, I wanted to create is DiskCopy 6.0 format, for both Mac OS 9 and Mac OS X.

GalainHH

[ Reply to This | # ]

I'm having the same issue, though I can see in the preferences file for DiskCopy that the change is there. For some reason, DiskCopy is not revealing the new features.

[ Reply to This | # ]

Works great. I used PrefEdit because I didn't want to hunt for files and won't like the Terminal until it handles "special" characters in paths in acceptable ways.

I had been waiting for a way to create DiskCopy 6 NDIF disk images under OS X since day 1 (compressed DiskCopy 6 images are my archive file format of choice, because they work under 9 and X and their content can be used right away - no 3d party utility and no decompression).

ShrinkWrap-made disk images with StuffIt internal compression seemed better since they were more comressed, but there's no way to mount them under OS X (even StuffIt Expander won't, because Aladdin bought ShrinkWrap to kill it when they realized it provided a much better archive solution than old-style compressed archives which can't be used in compressed form).

[ Reply to This | # ]

I couldn't convert a .dmg into a NDIF whereas I could create it from the mounted content of the dmg.

The converter seems to refuse some pairs of in/out formats.

[ Reply to This | # ]

I had been waiting for a way to create DiskCopy 6 NDIF disk images under OS X since day 1 (compressed DiskCopy 6 images are my archive file format of choice, because they work under 9 and X and their content can be used right away - no 3d party utility and no decompression).

Same here, this is a great tip. Thanks to the author !

-wp

[ Reply to This | # ]

While the "expert mode" options are available, at least one of them doesn't really work. Has anyone else successfully created a compressed, old style ".img" file? I've tried both on my iBook with 10.2.6 and a G4 with a clean install of OS X. The exact message is "failed to convert due to error 22. (Invalid argument)" - anyone else had this problem and/or know understand what's causing it?

I'm surprised no one else has had this problem.

[ Reply to This | # ]

I can create standard and compressed DMG files with no trouble, and I checked just to make sure it wasn't the missing "Temporary Items" folder issue that has been noted to cause this error.

On a side note, anyone have thoughts on using a disk image for Masters of Orion 3? I can't stand the way the play CD buzzes in my iBook drive, and therefor can't get into playing the game for hours on end. I was really hoping one of these new options would work, but it looks like I'm going to have to learn about the bowels of the OS to figure out how to put a disk image into the mount point of the CD-ROM drive...

[ Reply to This | # ]

This still works with Panther. You need to drag/copy/extract a Jag copy of Disk Copy to your Panther install.

Hugh

[ Reply to This | # ]

This seems to mostly work. I'm trying it on several systems and the stability is in doubt. Also, some of the options seem to result in errors though many of them work. If there is a category for sort of works please move it to that one.

Hugh

[ Reply to This | # ]

hdiutil's verb list has changed. Some of the disk copy features work and some do not. If you need one of the features, give it a shot. YMMV

Hugh

[ Reply to This | # ]

you can also use

defaults write com.apple.DiskUtility advanced-image-options 1

to have access to just the other image types

[ Reply to This | # ]