-.TH IMAGEX "1" "January 2013" "imagex (wimlib) wimlib @VERSION@" "User Commands"
+.TH IMAGEX "1" "March 2013" "imagex (wimlib) wimlib @VERSION@" "User Commands"
.SH NAME
imagex-apply \- Extract one image, or all images, from a WIM archive
\fBimagex 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)
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
well).
Here's an example. The names for the split WIMs usually go something like:
-
+
.RS
.PP
.nf
.RE
.PP
+.SH WINDOWS VERSION
+
+This section documents the differences between \fBimagex apply\fR in the Windows
+builds of wimlib versus the rest of this man page, which is written to document
+UNIX version.
+
+\fBimagex 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 mostly the same behavior as Microsoft's ImageX.
+
+\fB--hardlink\fR, \fB--symlink\fR, and \fB--unix-data\fR are not supported on
+Windows.
+
+Other than the differences documented in this section, the Windows version
+should be essentially equivalent to the UNIX version. However, one additional
+thing to note is that wimlib's Windows version of ImageX is NOT written to be
+command-line compatible with Microsoft's version of 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, \fBimagex apply\fR will ignore both
+Windows-style security descriptors and UNIX-specific file owners, groups, and
+modes set when using \fBimagex capture\fR with the \fB--unix-data\fR flag. By
+passing \fB--unix-data\fR to \fBimagex apply\fR instead, this causes this
+UNIX-specific data to be restored when available.
.SH NOTES
git://wimlib.net / wimlib / blobdiff