-.TH WIMLIB-IMAGEX "1" "March 2014" "@IMAGEX_PROGNAME@ @VERSION@" "User Commands"
+.TH WIMLIB-IMAGEX "1" "August 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
-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. However, by default, if
-\fB@IMAGEX_PROGNAME@\fR does not have permission to set the UNIX owner, group or
-file mode on an extracted file, a warning will be printed and it will not be
-considered an error condition; use \fB--strict-acls\fR to get stricter behavior.
+(UNIX-like systems only) Restore UNIX owners, groups, modes, and device IDs
+(major and minor numbers) that were captured by \fB@IMAGEX_PROGNAME@ capture\fR
+with the \fB--unix-data\fR option. As of wimlib v1.7.0, you can backup and
+restore not only the standard UNIX file permission information, but also
+character device nodes, block device nodes, named pipes (FIFOs), and UNIX domain
+sockets.
.TP
\fB--no-acls\fR
Do not restore security descriptors on extracted files and directories.
save the previous version in "\\System Volume
Information\\WimOverlay.wimlib_backup", which you potentially could restore if
you needed to.
+.IP ""
+You actually can still do a \fB--wimboot\fR extraction even if the WIM image is
+not marked as "WIMBoot-compatible". This option causes the extracted files to
+be set as "externally backed" by the WIM file. Microsoft's driver which
+implements this "external backing" functionality seemingly does not care whether
+the image(s) in the WIM are really marked as WIMBoot-compatible. Therefore, the
+"WIMBoot-compatible" tag (<WIMBOOT> in the XML data) seems to be a marker for
+intent only. In addition, the Microsoft driver can externally back files from
+WIM files that use XPRESS chunks of size 8192, 16384, and 32768, or LZX chunks
+of size 32768, in addition to the default XPRESS chunks of size 4096 that are
+created when \fB@IMAGEX_PROGNAME@ capture\fR is run with the \fB--wimboot\fR
+option.
.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