In the NTFS capture mode, do not capture security descriptors. This flag is
also available in the native Win32 build of wimlib.
.TP
+\fB--strict-acls\fR
+In the Win32 native build of wimlib, fail immediately if the full security
+descriptor of any file or directory cannot be read. The default behavior
+without this option is to first try omitting the SACL from the security
+descriptor, then to try omitting the security descriptor entirely. The purpose
+of this is to capture as much data as possible without always requiring
+Administrator privileges. However, if you desire that all security descriptors
+be captured exactly, you may with to provide this option, although the
+Administrator should have permission to read everything anyway.
+.TP
\fB--rpfix\fR, \fB--norpfix\fR
Set whether to fix targets of absolute symbolic links (reparse points in Windows
terminology) or not. When enabled (\fB--rpfix\fR), absolute symbolic links that
(\fB--source-list\fR specified), so you may wish to set \fB--norpfix\fR in that
case.
.TP
-\fB--strict-acls\fR
-In the Win32 native build of wimlib, fail immediately if the full security
-descriptor of any file or directory cannot be read. The default behavior
-without this option is to first try omitting the SACL from the security
-descriptor, then to try omitting the security descriptor entirely. The purpose
-of this is to capture as much data as possible without always requiring
-Administrator privileges. However, if you desire that all security descriptors
-be captured exactly, you may with to provide this option, although the
-Administrator should have permission to read everything anyway.
-.TP
\fB--source-list\fR
\fB@IMAGEX_PROGNAME@ capture\fR and \fB@IMAGEX_PROGNAME@ append\fR, as of wimlib 1.3.0, support a new
option to create a WIM image from multiple files or directories. When
stream chunk size of 32768. The only WIMs I've seen that are different from
this are some pre-Vista WIMs that had a different version number.
-Unless \fB--rebuild\fR is specified, aborting an \fB@IMAGEX_PROGNAME@ append\fR command
-mid-way through has a small chance of corrupting the WIM file. However, a
-precaution is taken against this, so it should be very unlikely. In the event
-of an aborted \fB@IMAGEX_PROGNAME@ append\fR, \fB@IMAGEX_PROGNAME@ optimize\fR may be run to remove
-extra data that may have been partially appended to the physical WIM file but
+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.
-Capturing or appending an image happens in two main phases: (1) scanning the
-directory or NTFS volume to checksum all the files and determine the streams to
-be written, and (2) writing the new streams to the WIM file. Streams are not
-stored in memory after (1), since there could easily be gigabytes of data;
-instead, they are read again during step (2); however, duplicate streams in the
-image, and streams already existing in any other image in the WIM, are not read
-again. In the future, it may be possible to introduce the ability to capture an
-image with reading each file only one time, although this mode would have some
-limitations--- for example, a stream might be compressed only to be thrown away
-as a duplicate once it's been checksummed.
-
\fISOURCE\fR may be a symbolic link to a directory rather than a directory
itself. However, additional symbolic links in subdirectories, or in additional
source directories not destined for the WIM image root (with
git://wimlib.net / wimlib / blobdiff