hdid(8) hdid(8)
NAME
hdid - HDI driver backing store service
SYNOPSIS
hdid [ options ] imagefile
DESCRIPTION
hdid is the user-level process which handles the loading
and decompression of disk image data for the HDI disk
image driver in the Mac OS X kernel. With OS X version
10.2 and later, certain read/write images and 10.2-gener-
ated zlib-compressed (UDZO) images attach in-kernel with-
out a persistent user process.
Using the DiskImages framework, hdid supports a variety of
flat-file and dual-fork image formats, including
read/write, read-only, and read-only compressed formats
(which it decompresses on the fly). It automatically
decodes AppleSingle and MacBinary file formats and is
capable of mounting most images directly from http://
URLs.
hdid is intended to be invoked by Disk Copy.app or hdiu-
til(1). However, it is identical to hdiutil attach and
can be used directly for attaching images to the system.
In either case, hdiutil detach or disktool -e should be
used to detach (aka "eject") them.
Please see the section below on setting up HTTP image
servers if you plan to regularly mount images from web
servers or are wondering why a particular image isn't
mounting over HTTP.
ARGUMENTS
-help show available options
-shadow [ <shadowfile> ]
Use a shadow file in conjunction with the data in
the image. This prevents modification of the orig-
inal image and allows read-only images to be
mounted read/write. When blocks are being read
from the image, blocks present in the shadow file
override blocks in the base image. When blocks are
being written, the writes will be redirected to the
shadow file. If not specified, -shadow defaults to
<imagename>.shadow. If the shadow file does not
exist, it is created.
-readonly
Attach the image file read only. Has no effect on
read-only images.
-readwrite
Attach the image file read/write. Has no effect on
read-only (or compressed) images. Used in some
cases where a read/write image file might default
to being inserting read-only.
-nomount
Suppress automatic mounting of the image or parti-
tions on it. This will result in /dev entries
being created, and (for non-kernel-attached images)
an hdid process in the background, but will not
mount the volumes.
-notremovable
Make the image appear to the system as a fixed
disk. A reboot will be required to cleanly detach
the image, though partitions can be unmounted and
remounted. This option requires root access, eg.
via sudo(8).
-encryption [ <crypto method> ]
This option specifies a particular encrypted encod-
ing. The default CEncryptedEncoding automatically
recognizes its images so this option should be
rarely needed. Be careful what you are asking for
if the -encryption flag comes directly before the
image name on the command line.
-passphrase <passphrase>
This option is provided for automation purposes but
is very insecure as the passphrase value will be
visible in the output of ps(1) (and thus perma-
nently visible to other users).
-imagekey <key>=<value>
Specify a key/value pair for the disk image recog-
nition and creation system. See hdiutil(1) for
more information.
-drivekey <keyname>=<value>
Specify a key/value pair for the IOHDIXHDDrive
object created (shows up in the IOKit registry of
devices which is viewable with ioreg(8)).
-kernel
attempt to attach the image in-kernel even if this
is not the default behavior for this type of image.
If the image can not be attached, no attempt will
be made to revert to attaching it with a persistent
hdid process.
-nokernel
attach the image with a persistent hdid process
instead of attaching in-kernel, even if the default
for this type of image is to attach in-kernel. Use
hdiutil(1)'s imageinfo verb to determine if an
image will default to mounting in-kernel.
-plist output a plist describing the image file and system
entities (dev entries, mount points, etc) that were
created.
-verbose
verbose output when inserting an image file
-debug diagnostic output when inserting an image file
-quiet When finished inserting the image file, don't echo
the dev entry created. This option doesn't do any-
thing. Use hdiutil mount instead.
EXAMPLES
$ hdid funstuff.img
Present funstuff.img to the filesystems for mounting.
$ hdid master.dmg -shadow
Present master.dmg to the filesystems for potential mount-
ing, redirecting all write operations to the shadow file
master.dmg.shadow.
$ hdid http://my.webserver.com/master.img -shadow
/tmp/mastershadowfile
Present master.img to the filesystems for potential mount-
ing, redirecting all write operations to the shadow file
mastershadowfile in /tmp. The shadow file can be on any
mounted read/write filesystem -- keep in mind the conse-
quences of using a remote filesystems (NFS, AFP) for such
shadow files.
hdid -nomount ram://<sectors>
will attach a ram disk that can be mounted and used after
being formatted with a newfs utility or Disk Utility.app.
A sector is 512 bytes.
A small shell script to create and mount a ram disk:
#!/bin/sh
NUMSECTORS=128000
mydev=`hdid -nomount ram://$NUMSECTORS`
newfs_hfs $mydev
mkdir /tmp/mymount
mount -t hfs $mydev /tmp/mymount
OUTPUT
Unless -plist is specified, hdid returns one line of out-
put per /dev entry created. Each line contains up to
three tab-delimited columns. The first column always con-
tains the full path to the /dev entry created. The second
column will contain the partition type if the image con-
tained a partition map. The third column will contain the
mountpoint if the particular /dev entry was mounted by
Disk Arbitration.
If hdid is asked to attach an image that is already
attached, it will attempt to return the usual information
for the attached image, as if it had just been attached.
However, if there are unmounted partitions on the attached
image, they will not be remounted.
Mounting Images via HTTP
In addition to mounting image files from local or remote
mounted filesystems, one can also mount image files from
HTTP servers. For flat image files (UDIF images, or
AppleSingle/MacBinary encoded NDIF image files) mounting a
image is a matter of passing the http:// URL to hdid:
hdid http://server.company.com/Images/stuff.dmg
If the image file to be served via HTTP is a dual fork
NDIF image that is not encoded into a flat-file format
such as AppleSingle, and the HTTP server is running on Mac
OS X, dual fork files may be detected and supported. Such
dual-fork files must be moved or copied using the Finder,
ditto -rsrcFork, or some other resource-fork-aware tool.
Properly copied dual-fork files on a UFS volume have a
._filename file in addition to the filename you see in the
Finder (i.e. stuff.img would also have ._stuff.img in the
same directory).
In either case, one would specify the URL to the data
fork, and hdid will determine if it is necessary to access
the secondary file.
Accessing dual fork files on HFS+ filesystems via HTTP is
only supported if the HTTP server is on a Mac OS X system.
It is possible that some options on the web server could
disable access to the resource fork on an HFS+ volume, but
no such options have yet been found.
Browsing images via HTTP is much more pleasant if the
server settings are modified to be more friendly to
highly-persistent clients. In particular for Apache, Max-
KeepAliveRequests should be increased significantly beyond
100 or set to 0 (unlimited) and KeepAliveTimeout should be
boosted to at least 30 (seconds). Increasing the number
of simultaneous clients may also be desirable because of
the increased delay before clients are forcibly discon-
nected.
While it is not directly related to mounting via hdid(1),
informing your web server that '.dmg' (and others) are
extensions associated with the MIME type applica-
tion/octet-stream will allow web browsers to download the
files rather than try to display them. For apache, you
add the extensions to the appropriate line in
/etc/httpd/mime.types.
FILES
/usr/libexec/load_hdi SUID executable used to load
HDI disk image driver
SEE ALSO
hdiutil(1), ditto(8), autodiskmount(8), ioreg(8)
25 June 2002 hdid(8)