-
-.SH SOURCE LIST MODE
-
-Yet another capture mode is entered when the \fB--source-list\fR option is
-given. It is essentially an extension of the \fBNORMAL MODE\fR that allows
-multiple files or directories to be incorporated into a WIM image using a single
-\fBimagex capture\fR or \fBimagex append\fR command. See the documentation for
-\fB--source-list\fR below.
-
-.SH WINDOWS VERSION
-
-This section documents the differences between \fBimagex capture\fR and
-\fBimagex append\fR in the Windows builds of wimlib versus the rest of this man
-page, which is written to document UNIX version.
-
-\fBimagex capture\fR and \fBimagex append\fR do not have separate "normal" and
-"NTFS" modes on Windows. There is simply one mode, and it uses the Windows API
-to capture NTFS-specific information, including alternate data streams, reparse
-points, hard links, and file attributes. So, you essentially get the advantages
-of the "NTFS mode" documented above, but you can capture a WIM image from any
-directory, not just an entire NTFS volume. This is mostly the same behavior as
-Microsoft's ImageX.
-
-The \fB--source-list\fR option is supported on Windows, but the
-\fB--dereference\fR option is not.
-
-Other than the differences documented in this section, the Windows version
-should be essentially equivalent to the UNIX version. However, one additional
-thing to note is that wimlib's Windows version of ImageX is NOT written to be
-command-line compatible with Microsoft's version of ImageX, although they are
-very similar.
-
+.SH DIRECTORY CAPTURE (WINDOWS)
+On Windows, \fB@IMAGEX_PROGNAME@ capture\fR and \fB@IMAGEX_PROGNAME@ append\fR
+natively support Windows-specific and NTFS-specific data. They therefore act
+similarly to the corresponding commands of Microsoft's ImageX. For best
+results, the directory being captured should be on an NTFS volume and
+\fB@IMAGEX_PROGNAME@\fR should be run with Administrator privileges; however,
+non-NTFS filesystems and running without Administrator privileges are also
+supported.
+.PP
+On Windows, \fB@IMAGEX_PROGNAME@ capture\fR and \fB@IMAGEX_PROGNAME@ append\fR
+try to archive as much data and metadata as possible, including:
+.IP \[bu] 4
+All data streams of all files, unless running on a version of Windows prior to
+Vista, in which case named data streams (if supported by the source filesystem)
+will not be captured.
+.IP \[bu]
+Reparse points, including symbolic links, junction points, and other reparse
+points, if supported by the source filesystem. (Note: see \fB--rpfix\fR and
+\fB--norpfix\fR for documentation on exactly how absolute symbolic links and
+junctions are captured.)
+.IP \[bu]
+File and directory creation, access, and modification timestamps. These are
+stored with Windows NT's native timestamp resolution of 100 nanoseconds.
+.IP \[bu]
+Security descriptors, if supported by the source filesystem and \fB--no-acls\fR
+is not specified. However, beware that unless \fB--strict-acls\fR is specified,
+the security descriptors for individual files or directories may be omitted or
+only partially captured if the user does not have permission to read them, which
+can be a problem if \fB@IMAGEX_PROGNAME@\fR is run as a non-Administrator.
+.IP \[bu]
+File attributes, including hidden, sparse, compressed, encrypted, etc.
+Encrypted files will be stored in encrypted form rather than in plain text.
+Transparently compressed files will be read as uncompressed and stored subject
+to the WIM's own compression. There is no special handling for storing sparse
+files, but they are likely to compress to a small size.
+.IP \[bu]
+DOS names (8.3) names of files; however, the failure to read them is not
+considered an error condition.
+.IP \[bu]
+Hard links, if supported by the source filesystem.
+.PP
+Note: the capture process is reversible, since when \fB@IMAGEX_PROGNAME@
+apply\fR (on Windows) extracts the captured WIM image, it will extract all of
+the above information, at least to the extent supported by the destination
+filesystem. One exception is that since encrypted files are stored as
+unencrypted, their data will not be available if restored on a Windows system
+that does not have the decryption key.