-.TH WIMLIB-IMAGEX "1" "March 2014" "@IMAGEX_PROGNAME@ @VERSION@" "User Commands"
+.TH WIMLIB-IMAGEX "1" "May 2014" "@IMAGEX_PROGNAME@ @VERSION@" "User Commands"
.SH NAME
@IMAGEX_PROGNAME@-apply \- Extract one image, or all images, from a WIM archive
.SH SYNOPSIS
thereof, in the case of \fB@IMAGEX_PROGNAME@ extract\fR) to a directory on
UNIX-like systems. See \fBDIRECTORY EXTRACTION (WINDOWS)\fR for the
corresponding documentation for Windows.
-
+.PP
As mentioned, a WIM image can be applied to a directory on a UNIX-like system by
providing a \fITARGET\fR directory. However, it is important to keep in mind
that the WIM format was designed for Windows, and as a result WIM files can
.IP \[bu] 4
Encrypted files will not be extracted.
.IP \[bu]
-Although sparse file attributes will be applied, the full data will be extracted
-to each sparse file, so extracted "sparse" files may not actually contain any
-sparse regions.
+wimlib v1.7.0 and later: Sparse file attributes will not be extracted (same
+behavior as ImageX/DISM/WIMGAPI). wimlib v1.6.2 and earlier: Although sparse
+file attributes will be applied, the full data will be extracted to each sparse
+file, so extracted "sparse" files may not actually contain any sparse regions.
.PP
Regardless, since almost all information from the WIM image is restored in this
mode, it is possible to restore an image of an actual Windows installation using
Reparse point fixups are never done in the NTFS volume extraction mode on
UNIX-like systems.
.TP
-\fB--hardlink\fR
-When extracting a file from the WIM that is identical to a file that has already
-extracted, create a hard link rather than creating a separate file. This option
-causes all identical files to be hard-linked, overriding the hard link groups
-that are specified in the WIM image(s). In the case of extracting all images
-from the WIM, files may be hard-linked even if they are in different WIM images.
-.IP ""
-However, hard-linked extraction mode does have some additional quirks. Named
-data streams will not be extracted, and files can be hard linked even if their
-metadata is not fully consistent.
-.TP
-\fB--symlink\fR
-This option is similar to \fB--hardlink\fR, except symbolic links are created
-instead.
-.TP
\fB--unix-data\fR
(UNIX-like systems only) By default, in the directory extraction mode on UNIX,
\fB@IMAGEX_PROGNAME@ apply\fR will ignore both Windows-style security
files" back to the WIM archive. This can result in significant space savings.
However, it comes at several potential costs, such as not being able to delete
the WIM archive and possibly having slower access to files. See Microsoft's
-documentation for "WIMBoot" for more information. Also, this option only works
-when several conditions hold:
-.RS
-.IP \[bu] 4
-The operating system is Windows 8.1 update 1 or later, since that is the first
-version of Windows that contains the Windows Overlay File System Filter Driver
-("WOF") necessary for this feature.
-.IP \[bu]
-The program is run as an Administrator.
-.IP \[bu]
-The WIM archive is not solid (i.e. is not an "ESD file").
-.IP \[bu]
-The target volume is NTFS or another filesystem that supports reparse points.
-.RE
+documentation for "WIMBoot" for more information.
+.IP ""
+If it exists, the [PrepopulateList] section of the file
+\\Windows\\System32\\WimBootCompress.ini in the WIM image will be read. Files
+matching any of these patterns will be extracted normally, not as WIMBoot
+"pointer files". This is helpful for certain files that Windows needs to read
+early in the boot process.
+.IP ""
+This option only works when the program is run as an Administrator and the
+target volume is NTFS or another filesystem that supports reparse points.
+.IP ""
+In addition, this option works best when running on Windows 8.1 Update 1 or
+later, since that is the first version of Windows that contains the Windows
+Overlay File System Filter Driver ("WOF"). If the WOF driver is detected,
+wimlib will create the WIMBoot "pointer files" using documented ioctls provided
+by WOF.
+.IP ""
+Otherwise, if the WOF driver is not detected, wimlib will create the reparse
+points and edit the file "\\System Volume Information\\WimOverlay.dat" on the
+target volume manually. This is potentially subject to problems, since although
+the code works in certain tested cases, neither of these data formats is
+actually documented by Microsoft. Before overwriting this file, wimlib will
+save the previous version in "\\System Volume
+Information\\WimOverlay.wimlib_backup", which you potentially could restore if
+you needed to.
.SH NOTES
\fIData integrity\fR: WIM files include SHA1 message digests for file data.
\fB@IMAGEX_PROGNAME@ apply\fR calculates the SHA1 message digest of every file
.PP
\fIDirectory traversal attacks\fR: wimlib validates filenames before extracting
them and is not vulnerable to directory traversal attacks. This is in contrast
-to Microsoft WIMGAPI/Imagex/Dism which can overwrite arbitrary files on the
+to Microsoft WIMGAPI/ImageX/DISM which can overwrite arbitrary files on the
target drive when extracting a malicious WIM file containing files named
\fI..\fR or containing path separators.
.SH EXAMPLES
git://wimlib.net / wimlib / blobdiff