-.TH IMAGEX "1" "January 2013" "imagex (wimlib) wimlib @VERSION@" "User Commands"
+.TH IMAGEX "1" "April 2013" "@IMAGEX_PROGNAME@ @VERSION@" "User Commands"
.SH NAME
-imagex-apply \- Extract one image, or all images, from a WIM archive
+@IMAGEX_PROGNAME@-apply \- Extract one image, or all images, from a WIM archive
.SH SYNOPSIS
-\fBimagex apply\fR \fIWIMFILE\fR \fIIMAGE\fR \fITARGET\fR [\fIOPTION\fR]...
+\fB@IMAGEX_PROGNAME@ apply\fR \fIWIMFILE\fR \fIIMAGE\fR \fITARGET\fR [\fIOPTION\fR]...
.SH DESCRIPTION
.PP
-\fBimagex apply\fR extracts an image, or all images, from the Windows Imaging
+\fB@IMAGEX_PROGNAME@ apply\fR extracts an image, or all images, from the Windows Imaging
(WIM) file \fIWIMFILE\fR.
+Note: this man page primarily documents the UNIX behavior. See \fBWINDOWS
+VERSION\fR for information specific to the Windows build of wimlib.
+
\fIIMAGE\fR specifies the WIM image to extract. It may be a 1-based index of an
image in the WIM, the name of an image in the WIM, or the keyword "all" to
-indicate that all images are to be extracted. Use the \fBimagex info\fR (1)
+indicate that all images are to be extracted. Use the \fB@IMAGEX_PROGNAME@ info\fR (1)
command to show what images a WIM file contains.
\fITARGET\fR specifies where to extract the WIM image(s) to. If \fITARGET\fR
specifies a regular file or block device, it is interpreted as a NTFS volume to
which the WIM image is to be extracted.
-\fBimagex apply\fR supports applying images from stand-alone WIMs as well as
+\fB@IMAGEX_PROGNAME@ apply\fR supports applying images from stand-alone WIMs as well as
split WIMs. See \fBSPLIT WIMS\fR.
.SH NORMAL MODE
Hard links
.IP \[bu]
File and directory creation, access, and modification timestamps to the nearest
-microsecond, if supported by the underlying filesystem
+100 nanoseconds, if supported by the underlying filesystem, operating system,
+and C library
.IP \[bu]
Symbolic links and junction points, although they will not necessarily point to
the desired location (for example, the target of the link may contain a Windows
extracted from the WIM image(s):
.IP \[bu] 4
-Security descriptors (file permissions)
+Security descriptors (file permissions) except through the extensions available
+through the \fB--unix-data\fR option
.IP \[bu]
The alternate (named) data streams for each file
.IP \[bu]
A special extraction mode is entered when \fITARGET\fR is a regular file or
block device. If this is the case, \fITARGET\fR is interpreted as an NTFS
volume and opened using libntfs-3g. If successful, the WIM image is extracted
-to the root of the NTFS volume in a special mode that preserves almost all
-information contained in the WIM image. \fIIMAGE\fR may not be "all" for this
-action.
+to the root of the NTFS volume in a special mode that preserves all information
+contained in the WIM image. \fIIMAGE\fR may not be "all" for this action.
The NTFS volume does not need to be empty, although it's expected that it be
empty for the intended use cases. A new NTFS filesystem can be created using
the \fBmkntfs\fR (8) command.
The NTFS extraction mode is not available if wimlib was compiled using the
---without-ntfs-3g option.
+\fB--without-ntfs-3g\fR option.
Please note that the NTFS extraction mode is \fInot\fR entered if \fITARGET\fR
is a directory, even if a NTFS filesystem is mounted on \fITARGET\fR. You must
.IP \[bu]
File attribute flags are applied.
.IP \[bu]
-Short (DOS) names for non-hard-linked files are extracted. The corresponding
-long name for each DOS name is made to be a Win32 name. Files with multiple
-hard links are extracted with filenames in the POSIX namespace, and short names
-(if any) are ignored. A singly-linked file with no short name is also extracted
-in the POSIX namespace. Note that this assigning of namespaces may not be
-exactly the same as in the original filesystem that was captured, and also this
-means that some DOS names may be lost (most likely inconsequentially).
+Short (DOS) names for files are extracted. The corresponding long name for each
+DOS name is made to be a Win32 name. Any additional names for the file in the
+same directory are made to be names in the POSIX namespace.
.PP
-Since almost all information from the WIM image is restored in the NTFS
-extraction mode, it is possible to restore an image of an actual Windows
-installation. In the examples at the end of this manual page, there is an
-example of applying an image from the "install.wim" file contained in the
-installation media for Windows Vista, Windows 7, and Windows 8 in the "sources"
-directory.
+Since all information from the WIM image is restored in the NTFS extraction
+mode, it is possible to restore an image of an actual Windows installation. In
+the examples at the end of this manual page, there is an example of applying an
+image from the "install.wim" file contained in the installation media for
+Windows Vista, Windows 7, and Windows 8 in the "sources" directory.
But in order to actually boot Windows from an applied image, you must understand
the boot process of Windows versions Vista and later. Basically, it is the
So let's say you applied an image from an existing "install.wim" as in the
example, or you've applied a custom Windows image that you've created using the
-\fBimagex capture\fR (1) command. You've just applied the "Boot" partition, or
+\fB@IMAGEX_PROGNAME@ capture\fR (1) command. You've just applied the "Boot" partition, or
the main Windows partition, but there is no "System" partition yet (i.e. no
\\BOOTMGR and no \\Boot\\BCD).
.SH SPLIT WIMS
-You may use \fBimagex apply\fR to apply images from a split WIM. The
+You may use \fB@IMAGEX_PROGNAME@ apply\fR to apply images from a split WIM. The
\fIWIMFILE\fR argument is used to specify the first part of the split WIM, and
the \fB--refs\fR="\fIGLOB\fR" option is used to provide a shell-style file glob
that specifies the additional parts of the split WIM. \fIGLOB\fR is expected to
well).
Here's an example. The names for the split WIMs usually go something like:
-
+
.RS
.PP
.nf
To apply the first image of this split WIM to the directory "dir", run:
.PP
.RS
-imagex apply mywim.swm 1 dir --ref="mywim*.swm"
+@IMAGEX_PROGNAME@ apply mywim.swm 1 dir --ref="mywim*.swm"
.RE
.PP
+.SH WINDOWS VERSION
+
+This section documents the differences between \fB@IMAGEX_PROGNAME@ apply\fR in the Windows
+builds of wimlib versus the rest of this man page, which is written to document
+the UNIX build.
+
+\fB@IMAGEX_PROGNAME@ apply\fR does not have separate "normal" and "NTFS" modes on Windows.
+There is simply one mode, and it uses the Windows API to apply NTFS-specific
+information, including alternate data streams, reparse points, hard links, and
+file attributes. So, you essentially get the advantages of the "NTFS mode"
+documented above, but you can apply the WIM image to any directory, not just an
+entire NTFS volume. This is essentially the same behavior as Microsoft's
+ImageX.
+
+\fB--hardlink\fR, \fB--symlink\fR, and \fB--unix-data\fR are not supported on
+Windows.
+
+Except for the differences documented in this section, the Windows build of
+\fB@IMAGEX_PROGNAME@ apply\fR should be essentially equivalent to the UNIX build. However,
+one additional thing to note is that wimlib's Windows ImageX is NOT written to
+be command-line compatible with Microsoft's ImageX, although they are very
+similar.
+
.SH OPTIONS
.TP 6
\fB--check\fR
\fB--ref\fR="\fIGLOB\fR"
File glob of additional split WIM parts that are part of the split WIM being
applied. See \fBSPLIT_WIMS\fR.
+.TP
+\fB--unix-data\fR
+This option may only be given in the normal extraction mode (not NTFS). By
+default, in the normal extraction mode on UNIX, \fB@IMAGEX_PROGNAME@ apply\fR
+will ignore both Windows-style security descriptors and UNIX-specific file
+owners, groups, and modes set when using \fB@IMAGEX_PROGNAME@ capture\fR with
+the \fB--unix-data\fR flag. By passing \fB--unix-data\fR to
+\fB@IMAGEX_PROGNAME@ apply\fR instead, this causes this UNIX-specific data to be
+restored when available.
+.TP
+\fB--no-acls\fR
+In the NTFS apply mode, do not apply security descriptors. This flag is also
+available in the native Win32 build of wimlib and may be useful when running
+\fB@IMAGEX_PROGNAME@\fR as a non-administrator.
+.TP
+\fB--strict-acls\fR
+Fail immediately if the full security descriptor of any file or directory cannot
+be set exactly as specified in the WIM file. The default behavior without this
+option is to fall back to setting a security descriptor with the SACL omitted,
+then only the default inherited security descriptor, if we do not have
+permission to set the desired one.
+.TP
+\fB--rpfix\fR, \fB--norpfix\fR
+Set whether to fix targets of absolute symbolic links (reparse points in Windows
+terminology) or not. When enabled (\fB--rpfix\fR), extracted absolute symbolic
+links that are marked in the WIM image as being fixed are assumed to have
+absolute targets relative to the image root, and therefore have the actual root
+of extraction prepended to their targets. The intention is that you can apply
+an image containing absolute symbolic links and still have them be valid after
+it's been applied to any location.
+
+The default behavior is \fB--rpfix\fR if any images in \fIWIMFILE\fR have been
+captured with reparse-point fixups done. Otherwise, it is \fB--norpfix\fR.
.SH NOTES
-\fBimagex apply\fR calculates the SHA1 message digest of every file stream it
+\fB@IMAGEX_PROGNAME@ apply\fR calculates the SHA1 message digest of every file stream it
extracts and verifies that it is the same as the SHA1 message digest provided in
the WIM file. It is an error if the message digests don't match. It's also
considered to be an error if any WIM resources cannot be found in the stream
lookup table. So you can be fairly certain that the file streams are extracted
-correctly, even though \fBimagex apply\fR don't have a \fB/verify\fR option like
-Microsoft's version of imagex does. Please note that this is separate from the
-integrity table of the WIM, which provides SHA1 message digests over raw chunks
-of the entire WIM file and is checked separately if the \fB--check\fR option is
+correctly, even though \fB@IMAGEX_PROGNAME@ apply\fR don't have a \fB/verify\fR option like
+Microsoft's ImageX does. Please note that this is separate from the integrity
+table of the WIM, which provides SHA1 message digests over raw chunks of the
+entire WIM file and is checked separately if the \fB--check\fR option is
specified.
-You cannot use \fBimagex apply\fR to apply a WIM from a pipe (such as standard
+You cannot use \fB@IMAGEX_PROGNAME@ apply\fR to apply a WIM from a pipe (such as standard
input) because the WIM file format is not designed for this.
.SH EXAMPLES
installation media to the directory "boot":
.RS
.PP
-image apply /media/windows/sources/boot.wim 1 boot
+@IMAGEX_PROGNAME@ apply /media/windows/sources/boot.wim 1 boot
.RE
.PP
Extract all images from the Windows PE image from the Windows Vista/7/8
installation media to the directory "boot", and hard link all identical files:
.RS
.PP
-image apply /media/windows8/sources/boot.wim all boot --hardlink
+@IMAGEX_PROGNAME@ apply /media/windows8/sources/boot.wim all boot --hardlink
.RE
.PP
.SS NTFS extraction mode
Apply a WIM image to a NTFS filesystem image:
.RS
.PP
-imagex apply mywim.wim 1 fsimage.ntfs
+@IMAGEX_PROGNAME@ apply mywim.wim 1 fsimage.ntfs
.RE
.PP
Create a new NTFS filesystem on the partition /dev/sda2 and apply the first
if you want to erase everything on that partition.)
.RS
.PP
-mkntfs /dev/sda2 && imagex apply /media/windows/sources/install.wim 1 /dev/sda2
+mkntfs /dev/sda2 && @IMAGEX_PROGNAME@ apply /media/windows/sources/install.wim 1 /dev/sda2
.RE
.PP
.SH SEE ALSO
-.BR imagex (1)
+.BR @IMAGEX_PROGNAME@ (1)
git://wimlib.net / wimlib / blobdiff