+# Overlay a separate directory directly on the root of the WIM image.
+# This is only legal if there are no conflicting files.
+/data/stuff /
+.RE
+.RE
+.fi
+.IP ""
+Subdirectories in the WIM are created as needed. Multiple source directories
+may share the same target, which implies an overlay; however, an error is issued
+if the same file appears in different overlays to the same directory.
+.IP ""
+File paths containing whitespace may be quoted with either single quotes or
+double quotes. Quotes may not be escaped.
+.IP ""
+Lines consisting only of whitespace and lines beginning with '#' preceded by
+optional whitespace are ignored.
+.IP ""
+As a special case, if \fISOURCE\fR is "-", the source list is read from standard
+input rather than an external file.
+.IP ""
+The NTFS volume capture mode on UNIX-like systems cannot be used with
+\fB--source-list\fR, as only capturing a full NTFS volume is supported.
+.TP
+\fB--pipable\fR
+Create a "pipable" WIM, which can be applied fully sequentially, including from
+a pipe. An image in the resulting WIM can be applied with \fB@IMAGEX_PROGNAME@
+apply\fR, either normally by specifying the WIM file name, or with
+\fB@IMAGEX_PROGNAME@ apply -\fR to read the WIM from standard input. See
+\fB@IMAGEX_PROGNAME@ apply\fR(1) for more details.
+.IP ""
+For append operations, this option will result in a full rebuild of the WIM to
+make it pipable. For capture operations, the captured WIM is simply created as
+pipable. Beware that the more images you add to a pipable WIM, the less
+efficient piping it will be, since more unneeded data will be sent through the
+pipe.
+.IP ""
+When wimlib creates a pipable WIM, it carefully re-arranges the components of
+the WIM so that they can be read sequentially and also makes several other
+modifications. As a result, these "pipable" WIMs are \fInot compatible with
+Microsoft's software\fR, so keep this in mind if you're going to use them. If
+desired, you can use \fB@IMAGEX_PROGNAME@ optimize --not-pipable\fR to re-write
+a pipable WIM as a regular WIM. (\fB@IMAGEX_PROGNAME@ export\fR also provides
+the capability to export images from a pipable WIM into a non-pipable WIM, or
+vice versa.)
+.IP ""
+For the most part, wimlib operates on pipable WIMs transparently. You can
+modify them, add or delete images, export images, and even create split pipable
+WIMs. The main disadvantages are that appending is (currently) less efficient
+(\fB--rebuild\fR is always implied), and also they aren't compatible with
+Microsoft's software.
+.IP ""
+\fB@IMAGEX_PROGNAME@ capture\fR and \fB@IMAGEX_PROGNAME@ append\fR can both
+write a pipable WIM directly to standard output; this is done automatically if
+\fIWIMFILE\fR is specified as "-". (In that case, \fB--pipable\fR is assumed.)
+.TP
+\fB--not-pipable\fR
+Ensure the resulting WIM is in the normal, non-pipable WIM format. This is the
+default for \fB@IMAGEX_PROGNAME@ capture\fR, except when writing to standard
+output (\fIWIMFILE\fR specified as "-"), and also for \fB@IMAGEX_PROGNAME@
+append\fR, except when appending to a WIM that is already pipable.
+.TP
+\fB--update-of\fR=[\fIWIMFILE\fR:]\fIIMAGE\fR
+Declares that the image being captured or appended from \fISOURCE\fR is mostly the same as
+the existing image \fIIMAGE\fR in \fIWIMFILE\fR, but captured at a later point
+in time, possibly with some modifications in the intervening time. This is
+designed to be used in incremental backups of the same filesystem or directory
+tree. \fIIMAGE\fR can be a 1-based index or name of an existing image in
+\fIWIMFILE\fR. It can also be a negative integer to index backwards into the
+images (e.g. -1 means the last existing image in \fIWIMFILE\fR).
+.IP ""
+When this option is provided, the capture or append of the new image will be
+optimized by not reading files that, based on metadata such as timestamps,
+appear not to have been modified since they were archived in the existing
+\fIIMAGE\fR. Barring manipulation of timestamps, this option only affects
+performance and does not change the resulting WIM image.
+.IP ""
+As shown, the full syntax for the argument to this option is to specify the WIM
+file, a colon, and the image; for example, "--update-of mywim.wim:1". However,
+the WIM file and colon may be omitted, in which case the WIM file will default
+to the WIM file being appended to for append operations, or the WIM file from
+which a delta is being taken (only if \fB--delta-from\fR is specified exactly
+once) for capture operations.
+.TP
+\fB--delta-from\fR=\fIWIMFILE\fR
+For \fB@IMAGEX_PROGNAME@ capture\fR only: capture the new WIM as a "delta" from
+\fIWIMFILE\fR. Any streams that would ordinarily need to be archived in the new
+WIM are omitted if they are already present in the \fIWIMFILE\fR on which the
+delta is being based. The new WIM will still contain a full copy of the image
+metadata, but this is typically only a small fraction of a WIM's total size.
+.IP ""
+This option can be specified multiple times, in which case the resulting delta
+WIM will only contain streams not present in any of the specified base
+\fIWIMFILE\fRs.
+.IP ""
+To operate on the resulting delta WIM using other commands such as
+\fB@IMAGEX_PROGNAME@ apply\fR, you must specify the delta WIM as the WIM file to
+operate on, but also reference the base WIM(s) using the \fB--ref\fR option.
+Beware: to retain the proper functioning of the delta WIM, you can only add, not
+delete, files and images to the base WIM(s) following the capture of a delta
+from it.
+.IP ""
+\fB--delta-from\fR may be combined with \fB--update-of\fR to increase the
+speed of capturing a delta WIM.
+.IP ""
+As an example, consider the following backup and restore sequence:
+.IP ""
+.RS
+.nf
+(initial backup)
+
+$ wimcapture /some/directory bkup-base.wim
+
+(some days later, create second backup as delta from first)
+
+$ wimcapture /some/directory bkup-2013-08-20.dwm \\
+ --update-of bkup-base.wim:-1 --delta-from bkup-base.wim
+
+(restoring the second backup)
+
+$ wimapply bkup-2013-08-20.dwm --ref=bkup-base.wim 1 \\
+ /some/directory
+.RE
+.fi
+.IP ""
+However, note that as an alternative to the above sequence that used a delta
+WIM, the second backup could have simply been appended to the WIM as new image
+using \fB@IMAGEX_PROGNAME@ append\fR. Delta WIMs should be used only if it's
+desired to base the backups or images on a separate, large file that is rarely
+modified.
+.IP ""
+Note: unlike "pipable" WIMs (created with the \fB--pipable\fR option), "delta"
+WIMs (created with the \fB--delta-from\fR option) are compatible with
+Microsoft's software. You can use the /ref option of imagex.exe to reference
+the base WIM(s), similar to above.
+.IP ""
+Additional note: \fB@IMAGEX_PROGNAME@\fR is generalized enough that you can in
+fact combine \fB--pipable\fR and \fB--delta-from\fR to create pipable delta
+WIMs. In such cases, the base WIM(s) must be captured as pipable as well as the
+delta WIM, and when applying an image, the base WIM(s) must be sent over the
+pipe after the delta WIM.
+.SH NOTES
+\fB@IMAGEX_PROGNAME@ append\fR does not support appending an image to a split WIM.
+.PP
+It is safe to abort an \fB@IMAGEX_PROGNAME@ append\fR command partway through;
+however, after doing this, it is recommended to run \fB@IMAGEX_PROGNAME@
+optimize\fR to remove any data that was appended to the physical WIM file but
+not yet incorporated into the structure of the WIM, unless the WIM was being
+fully rebuilt (e.g. with \fB--rebuild\fR), in which case you should delete the
+temporary file left over.
+.PP
+\fB@IMAGEX_PROGNAME@\fR creates WIMs compatible with Microsoft's software
+(imagex.exe, Dism.exe, wimgapi.dll), with some caveats:
+.IP \[bu] 4
+With \fB@IMAGEX_PROGNAME@\fR on UNIX-like systems, it is possible to create a
+WIM image containing files with names differing only in case, or files with
+names containing the characters ':', '*', '?', '"', '<', '>', '|', or '\\',
+which are valid on POSIX-compliant filesystems but not Windows. Be warned that
+such files will not be extracted by default by the Windows version of
+\fB@IMAGEX_PROGNAME@\fR, and (even worse) Microsoft's ImageX can be confused by
+such names and quit extracting the image partway through. (It perhaps is worth
+pointing out that Windows' own default filesystem, NTFS, supports these
+characters, although Windows does not!)
+.IP \[bu]
+WIMs captured with \fB--unix-data\fR should be assumed to be incompatible with
+Microsoft's software.
+.IP \[bu]
+Pipable WIMs are incompatible with Microsoft's software. Pipable WIMs are
+created only if \fIWIMFILE\fR was specified as "-" (standard output) or if
+the \fB--pipable\fR flag was specified.
+.IP \[bu]
+WIMs captured with a non-default chunk size (with the \fB--chunk-size\fR option)
+or as solid archives (with the \fB--pack-streams\fR option) or with LZMS
+compression (with \fB--compress\fR=LZMS or \fB--compress\fR=recovery) have
+varying levels of compatibility with Microsoft's software. The best
+compatibility is achieved with WIMGAPI itself (not ImageX or Dism) on Windows 8
+or later.
+.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
+the image name need not be specified and will default to 'somedir':
+.RS
+.PP
+@IMAGEX_PROGNAME@ capture somedir mywim.wim --compress=maximum
+.RE
+.PP
+or, if the \fBwimcapture\fR hard link or batch file has been installed, the
+abbreviated form can be used:
+.RS
+.PP
+wimcapture somedir mywim.wim --compress=maximum
+.RE
+.PP
+The remaining examples will use the long form, however. Next, append the image
+of a different directory tree to the WIM created above:
+.RS
+.PP
+@IMAGEX_PROGNAME@ append anotherdir mywim.wim
+.RE
+.PP
+Easy enough, and the above examples of imaging directory trees work on both
+UNIX-like systems and Windows. Next, capture a WIM with several non-default
+options, including "fast" (XPRESS) compression, an integrity table, no messing
+with absolute symbolic links, and an image name and description:
+.RS
+.PP
+@IMAGEX_PROGNAME@ capture somedir mywim.wim --compress=fast \\
+.RS
+--check --norpfix "Some Name" "Some Description"
+.RE
+.RE
+.PP
+Capture an entire NTFS volume into a new WIM file and name the image "Windows
+7". On UNIX-like systems, this requires using the special mode described in
+\fBNTFS VOLUME CAPTURE (UNIX)\fR where \fISOURCE\fR is a file or block device
+containing an NTFS filesystem:
+.RS
+.PP
+@IMAGEX_PROGNAME@ capture /dev/sda2 windows7.wim "Windows 7"
+.RE
+.PP
+or, on Windows, to capture a full NTFS volume you instead need to specify the
+root directory of the mounted volume, for example:
+.RS
+.PP
+@IMAGEX_PROGNAME@ capture E:\\ windows7.wim "Windows 7"
+.RE
+.PP
+Same as above example with capturing an NTFS volume from \fB@IMAGEX_PROGNAME@\fR
+running on a UNIX-like system, but capture the WIM in the wimlib-specific
+"pipable" format that can be piped to \fB@IMAGEX_PROGNAME@ apply\fR:
+.RS
+.PP
+@IMAGEX_PROGNAME@ capture /dev/sda2 windows7.wim "Windows 7" \\
+.br
+.RS
+--pipable
+.RE
+.RE
+.PP
+Same as above, but instead of writing the pipable WIM to the file
+"windows7.wim", write it directly to standard output through a pipe into some
+other program "someprog", which could, for example, be a program or script that
+streams the data to a server. Note that \fB--pipable\fR need not be explicitly
+specified when using standard output as the WIM "file":
+.RS
+.PP
+@IMAGEX_PROGNAME@ capture /dev/sda2 - "Windows 7" | someprog
+.RE
+.SH SEE ALSO
+.BR @IMAGEX_PROGNAME@ (1),
+.BR @IMAGEX_PROGNAME@-apply (1)