imagex-capture.1.in: Update

[wimlib] / doc / man1 / imagex-apply.1.in

diff --git a/doc/man1/imagex-apply.1.in b/doc/man1/imagex-apply.1.in
index cf29277351d320dc7b9a1e2ba5ec674f57c64852..858634558ba6a32885310375c7b6184f049d12e7 100644 (file)
--- a/doc/man1/imagex-apply.1.in
+++ b/doc/man1/imagex-apply.1.in
@@ -1,4 +1,4 @@
-.TH WIMLIB-IMAGEX "1" "May 2014" "@IMAGEX_PROGNAME@ @VERSION@" "User Commands"
+.TH WIMLIB-IMAGEX "1" "June 2014" "@IMAGEX_PROGNAME@ @VERSION@" "User Commands"
 .SH NAME
 @IMAGEX_PROGNAME@-apply \- Extract one image, or all images, from a WIM archive
 .SH SYNOPSIS
@@ -49,7 +49,7 @@ This section documents how \fB@IMAGEX_PROGNAME@ apply\fR (and also
 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
@@ -124,7 +124,7 @@ mode:
 .IP \[bu] 4
 Encrypted files will not be extracted.
 .IP \[bu]
-wimlib v1.6.3 and later:  Sparse file attributes will not be extracted (same
+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.
@@ -330,31 +330,13 @@ captured with reparse-point fixups done.  Otherwise, it is \fB--norpfix\fR.
 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.
@@ -424,6 +406,18 @@ 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.
+.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