]> wimlib.net Git - wimlib/blobdiff - doc/imagex-capture.1.in
Add support for extract list files
[wimlib] / doc / imagex-capture.1.in
index 08ac4226735bb10a22328ab3ef8fc0340b51c93a..8b70c9ba3e301ea585ff0a2369bf0d56c41ab9d4 100644 (file)
@@ -1,4 +1,4 @@
-.TH WIMLIB-IMAGEX "1" "October 2013" "@IMAGEX_PROGNAME@ @VERSION@" "User Commands"
+.TH WIMLIB-IMAGEX "1" "December 2013" "@IMAGEX_PROGNAME@ @VERSION@" "User Commands"
 .SH NAME
 @IMAGEX_PROGNAME@-capture, @IMAGEX_PROGNAME@-append \- Create or append a WIM image
 .SH SYNOPSIS
@@ -180,26 +180,55 @@ table if and only if one was present before.
 \fB--compress\fR=\fITYPE\fR
 Specifies the compression type for the new WIM file.  This flag is only valid
 for \fB@IMAGEX_PROGNAME@ capture\fR, since the compression mode for
-\fB@IMAGEX_PROGNAME@ append\fR must be the same as that of the existing WIM (and
-is automatically set as such).
-\fITYPE\fR may be "none", "fast", or "maximum".  By default, it is "maximum".
-This default behavior is different from Microsoft's ImageX, where the default is
-"fast". \fB@IMAGEX_PROGNAME@ capture\fR instead gives you the better compression
-ratio by default and makes up for the slightly slower compression by being
-faster than Microsoft's software in the first place and using multiple CPUs when
-available.
+\fB@IMAGEX_PROGNAME@ append\fR must be the same as that of the existing
+WIM (and is automatically set as such).  \fITYPE\fR may be "none",
+"fast", or "maximum".  As of wimlib v1.5.3, the default is LZX compression, but
+in a special mode that is somewhere in between "fast" and "maximum" in terms of
+speed and compression ratio.  Use \fB--compress\fR=\fImaximum\fR to explicitly
+request a better compression ratio at the cost of more time spent compressing.
 .IP ""
 You may also specify the actual names of the compression algorithms, "XPRESS"
 and "LZX", instead of "fast" and "maximum", respectively.
+.IP ""
+As of wimlib v1.6.0, a third compression type, "recovery" or "LZMS", is also
+available.  Its use is not recommended because other than wimlib itself, as of
+Windows 8 it is only compatible with WIMGAPI and Windows Setup (not even ImageX
+or Dism).  Furthermore, wimlib's LZMS compressor is currently less well
+optimized than its LZX compressor.  However, LZMS is the compression algorithm
+used in packed resources created if the \fB--pack-streams\fR option is
+specified.
 .TP
 \fB--compress-slow\fR
-Spend even more time compressing the data in order to achieve a higher
-compression ratio.  Currently, this only has an effect with LZX ("maximum")
-compression.  Depending on the data, compressing with this option will take
-around 10 to 15 times longer and produce a LZX-compressed WIM about 1% to 5%
-smaller than one produced with the default LZX compressor.  Depending on the
-data, the resulting WIM may be approximately the same size (typically no more
-than 0.4% different) as a LZX-compressed WIM produced by WIMGAPI.
+Like \fB--compress\fR=\fImaximum\fR, but spend even more time compressing the
+data to achieve a very slightly better compression ratio.
+.TP
+\fB--chunk-size\fR=\fISIZE\fR
+Set the WIM compression chunk size to \fISIZE\fR.  Using this option is not
+recommended because WIM chunk sizes other than the default of 32768 have varying
+levels of compatibility with Microsoft's software (depending on the compression
+type, chunk size, and software version).  In addition, wimlib versions before
+1.6.0 do not support alternate chunk sizes.  But if you decide to use this
+option regardless, you can choose a chunk size that is a power of 2 greater than
+or equal to 2^15 (32768) up to a maximum determined by the compression format.
+Larger chunks mean larger LZ77 dictionaries and better compression ratios on
+sufficiently large files, but slower random access.  For LZX ("maximum")
+compression, the maximum allowed chunk size is 2^21 (2097152), and for XPRESS
+("fast") and LZMS ("recovery") compression, the maximum allowed chunk size is
+2^26 (67108644).
+.TP
+\fB--pack-streams\fR
+Create a "solid" archive that compresses multiple unique streams ("files")
+together, rather than each unique stream ("file") independently.  This can
+result in a significantly better compression ratio, but this format greatly
+decreases the performance of random access to the data, as may occur on a WIM
+mounted with \fB@IMAGEX_PROGNAME@ mount\fR.  Also, WIMs created using this
+option use a different version number in their header and as of Windows 8 are
+only compatible with Windows Setup and WIMGAPI, not even ImageX and Dism.
+.IP ""
+Packed resources use a chunk size that is independent of the WIM's "default
+chunk size", the latter of which may be adjusted by the \fB--chunk-size\fR
+option.  For compatibility reasons, there is currently no option to change the
+compression algorithm or chunk size used in packed resources.
 .TP
 \fB--threads\fR=\fINUM_THREADS\fR
 Number of threads to use for compressing data.  Default: autodetect (number of
@@ -215,9 +244,6 @@ optimize\fR(1).
 Specify a string to use in the <FLAGS> element of the XML data for the new
 image.
 .TP
-\fB--verbose\fR
-Print the names of files and directories as they are captured.
-.TP
 \fB--dereference\fR
 (UNIX-like systems only) Follow symbolic links and archive the files they point
 to, rather than archiving the links themselves.
@@ -508,12 +534,10 @@ the \fB--pipable\fR flag was specified.
 .SH EXAMPLES
 First example:  Create a new WIM 'mywim.wim' with "maximum" (LZX) compression
 that will contain a captured image of the directory tree 'somedir'.  Note that
-\fB@IMAGEX_PROGNAME@\fR uses "maximum" (LZX) compression by default, so
-\fB--compress\fR does \fInot\fR need to be specified; furthermore, the image
-name need not be specified and will default to 'somedir':
+the image name need not be specified and will default to 'somedir':
 .RS
 .PP
-@IMAGEX_PROGNAME@ capture somedir mywim.wim
+@IMAGEX_PROGNAME@ capture somedir mywim.wim --compress=maximum
 .RE
 .PP
 or, if the \fBwimcapture\fR hard link or batch file has been installed, the