--- /dev/null
+scan-build --use-analyzer=/bin/clang clang src/*.c programs/imagex.c -o imagex -D_FILE_OFFSET_BITS=64 -std=gnu99 -lntfs-3g -lxml2 -lfuse -lpthread -lrt -Iinclude/ -I./ -I/usr/include/libxml2/ -D HAVE_CONFIG_H -Wno-pointer-sign -D_GNU_SOURCE -lcrypto
all.
.SH NTFS VOLUME EXTRACTION (UNIX)
This section documents how \fB@IMAGEX_PROGNAME@ apply\fR extracts a WIM image
-directly to an NTFS volume image on UNIX-like systems. See \fBDIRECTORY EXTRACTION
-(WINDOWS)\fR for the corresponding documentation for Windows.
+directly to an NTFS volume image on UNIX-like systems.
.PP
As mentioned, \fB@IMAGEX_PROGNAME@\fR running on a UNIX-like system can apply a
WIM image directly to an NTFS volume by specifying \fITARGET\fR as a regular file
This NTFS volume extraction mode attempts to extract as much information as
possible, including:
.IP \[bu] 4
-All data streams of all files, including the unnamed data stream as well as all
-named data streams.
+All data streams of all files except encrypted files, including the unnamed data
+stream as well as all named data streams.
.IP \[bu]
Reparse points, including symbolic links, junction points, and other reparse
points.
.IP \[bu]
Since encrypted files (with FILE_ATTRIBUTE_ENCRYPTED) are not stored in
plaintext in the WIM image, \fB@IMAGEX_PROGNAME@\fR cannot restore encrypted
-files to filesystems not supporting encryption. Therefore, such files are not
-extracted. Furthermore, even if encrypted files are restored to a filesystem
-that supports encryption, they will only be decryptable if the decryption key is
-available.
+files to filesystems not supporting encryption. Therefore, on such filesystems,
+encrypted files will not be extracted. Furthermore, even if encrypted
+files are restored to a filesystem that supports encryption, they will only be
+decryptable if the decryption key is available.
.IP \[bu]
Files with names that cannot be represented on Windows will not
be extracted by default; see \fB--include-invalid-names\fR.
.IP \[bu]
-Files with full paths over 260 characters (MAX_PATH) are extracted by using the
-\\\\?\\-prefixed path hack. But beware that such files will be inaccessible to
-most Windows software and may not be able to be deleted easily.
+Files with full paths over 260 characters (the so-called MAX_PATH) will be
+extracted, but beware that such files will be inaccessible to most Windows
+software and may not be able to be deleted easily.
.SH SPLIT WIMS
You may use \fB@IMAGEX_PROGNAME@ apply\fR to apply images from a split WIM. The
\fIWIMFILE\fR argument must specify the first part of the split WIM, while the
nonseekable file, such as a pipe, provided that the WIM was captured with
\fB--pipable\fR (see \fB@IMAGEX_PROGNAME@ capture\fR(1)). To use standard input
as the WIM, specify "-" as \fIWIMFILE\fR. A useful use of this ability is to
-apply an image from a WIM while streaming it from a webserver; for example, to
-apply the first image from a WIM file to an NTFS volume on /dev/sda1:
+apply an image from a WIM while streaming it from a server. For example, to
+apply the first image from a WIM file available on a HTTP server to an NTFS
+volume on /dev/sda1, run something like:
.PP
.RS
wget -O - http://myserver/mywim.wim | wimapply - 1 /dev/sda1
Set whether to fix targets of absolute symbolic links (reparse points in Windows
terminology) or not. When enabled (\fB--rpfix\fR), extracted absolute symbolic
links that are marked in the WIM image as being fixed are assumed to have
-absolute targets relative to the image root, and therefore have the actual root
-of extraction prepended to their targets. The intention is that you can apply
-an image containing absolute symbolic links and still have them be valid after
-it has been applied to any location.
+absolute targets relative to the image root, and therefore \fB@IMAGEX_PROGNAME@
+apply\fR prepends the absolute path to the extraction target directory to their
+targets. The intention is that you can apply an image containing absolute
+symbolic links and still have them be valid after it has been applied to any
+location.
.IP ""
The default behavior is \fB--rpfix\fR if any images in \fIWIMFILE\fR have been
captured with reparse-point fixups done. Otherwise, it is \fB--norpfix\fR.
.IP ""
Reparse point fixups are never done in the NTFS volume extraction mode on
UNIX-like systems.
-.IP ""
-\fB--verbose\fR
-Print the path to of each file or directory within the WIM image as it is
-extracted.
.TP
\fB--hardlink\fR
When extracting a file from the WIM that is identical to a file that has already
.TP
\fB--strict-acls\fR
Fail immediately if the full security descriptor of any file or directory cannot
-be set exactly as specified in the WIM file. On Windows, the default behavior
-without this option is to fall back to setting a security descriptor with the
-SACL omitted, then only the default inherited security descriptor, if
-\fB@IMAGEX_PROGNAME@\fR does not have permission to set the desired one. Also,
-on UNIX-like systems, this flag can also be combined with \fB--unix-data\fR to
-cause \fB@IMAGEX_PROGNAME@\fR to fail immediately if the UNIX owner, group, or
-mode on an extracted file cannot be set for any reason.
+be set exactly as specified in the WIM file. If this option is not specified,
+when \fB@IMAGEX_PROGNAME@\fR on Windows does not have permission to set a
+security descriptor on an extracted file, it falls back to setting it only
+partially (e.g. with SACL omitted), and in the worst case omits it entirely.
+However, this should only be a problem when running \fB@IMAGEX_PROGNAME@\fR
+without Administrator rights. Also, on UNIX-like systems, this flag can also be
+combined with \fB--unix-data\fR to cause \fB@IMAGEX_PROGNAME@\fR to fail
+immediately if the UNIX owner, group, or mode on an extracted file cannot be set
+for any reason.
.TP
\fB--include-invalid-names\fR
Extract files and directories with invalid names by replacing characters and
-appending a suffix rather than ignoring them. The meaning of this is
-platform-dependent.
-.IP "" 6
+appending a suffix rather than ignoring them. Exactly what is considered an
+"invalid" name is platform-dependent.
+.IP ""
On POSIX-compliant systems, filenames are case-sensitive and may contain any
byte except '\\0' and \'/', so on a POSIX-compliant system this option will only
have an effect in the unlikely case that the WIM image for some reason has a
filename containing one of these characters.
-.IP "" 6
+.IP ""
On Windows, filenames are case-insensitive, cannot include the characters '/',
\'\\0', '\\', ':', '*', '?', '"', '<', '>', or '|', and cannot end with a space
or period. Ordinarily, files in WIM images should meet these conditions as
\fISOURCE\fR specifies the location of the files to create the new WIM image
from. If \fISOURCE\fR is a directory, the WIM image is captured from that
directory (see \fBDIRECTORY CAPTURE (UNIX)\fR or \fBDIRECTORY CAPTURE
-(WINDOWS)\fR. Alternatively, if the \fB--source-list\fR option is specified,
+(WINDOWS)\fR). Alternatively, if the \fB--source-list\fR option is specified,
\fISOURCE\fR is interpreted as a file that itself provides a list of
files and directories to include in the new WIM image. Still
alternatively, only on UNIX-like systems, if \fISOURCE\fR is a
regular file or block device, it is interpreted as an NTFS volume from
which a WIM image is to be captured using libntfs-3g (see \fBNTFS VOLUME CAPTURE
-(UNIX)\fR.
+(UNIX)\fR).
.PP
\fIIMAGE_NAME\fR and \fIIMAGE_DESCRIPTION\fR specify the name and description to
give the new WIM image. If \fIIMAGE_NAME\fR is not specified, it defaults to
UNIX file owners, groups, and modes. (Exception: see the \fB--unix-data\fR
option.) As a result, file permissions will not be stored, and files that are
neither regular files, directories, nor symbolic links, such as device files and
-FIFOs, cannot be captured.
+FIFOs, cannot be captured and will be excluded by default.
.IP \[bu]
Extended attributes. This mainly includes extensions to the traditional UNIX
security model, such as SELinux security labels, POSIX ACLs, and capabilities
labels.
-.IP \[bu]
-Files that are neither regular files, directories, nor symbolic links, such as
-device files and FIFOs. These will be excluded by default.
.PP
Notes: hard links and symbolic links are supported by the WIM format and
\fIare\fR stored. (Symbolic links are turned into "native" Windows symbolic
(atime), but not last status change time (ctime).
.SH NTFS VOLUME CAPTURE (UNIX)
This section documents how \fB@IMAGEX_PROGNAME@\fR captures files directly from
-an NTFS volume image on UNIX-like systems. See \fBDIRECTORY CAPTURE
-(WINDOWS)\fR for the corresponding documentation for Windows.
+an NTFS volume image on UNIX-like systems.
.PP
On UNIX-like systems, a special image capture mode is entered when \fISOURCE\fR
is a regular file or block device. In this mode, \fISOURCE\fR is assumed to be
-an NTFS volume or volume image, and wimlib will capture a WIM image containing a
-full contents of the NTFS volume, including NTFS-specific data. This is done
-using libntfs-3g.
+an NTFS volume or volume image, and \fB@IMAGEX_PROGNAME@\fR will capture a WIM
+image containing the full contents of the NTFS volume, including NTFS-specific
+data. This is done using libntfs-3g.
.PP
Please note that the NTFS volume capture mode is \fInot\fR entered if
\fISOURCE\fR is a directory, even if an NTFS filesystem is mounted on
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
+encrypted, their data will not be available if restored on a Windows system
that does not have the decryption key.
.SH OPTIONS
.TP 6
existed and was already pipable, or was "-" (standard output).
.TP
\fB--not-pipable\fR
-Build, or rebuld, \fIDEST_WIMFILE\fR as a normal, non-pipable WIM. This is the
+Build, or rebuild, \fIDEST_WIMFILE\fR as a normal, non-pipable WIM. This is the
default behavior, unless \fIDEST_WIMFILE\fR already existed and was already
pipable, or if \fIDEST_WIMFILE\fR was "-" (standard output).
.SH SPLIT WIMS
* @name Init flags
*
* The following flags can be passed to wimlib_global_init().
+ * @{
*/
/** Assume that strings are represented in UTF-8, even if this is not the
*
* The following flags can be passed to wimlib_reference_resource_files() and
* wimlib_reference_resources().
+ * @{
*/
/** wimlib_reference_resource_files() only: Enable shell-style filename
* wimlib_resolve_image() uses. However, unlike wimlib_extract_image(),
* only a single image (not all images) can be specified. Alternatively,
* specify @p NULL here to use the first image in the WIM if it contains
- * exactly one image but otherwise return @p WIMLIB_ERR_INVALID_IMAGE.
+ * exactly one image but otherwise return ::WIMLIB_ERR_INVALID_IMAGE.
* @param target
* Same as the corresponding parameter to wimlib_extract_image().
* @param extract_flags
* Number of filenames in @p swms.
* @param swm_open_flags
* Open flags for the split WIM parts (e.g.
- * ::WIMLIB_OPEN_FLAG_CHECK_INTEGRITY). Note: WIMLIB_OPEN_FLAG_SPLIT_OK is
- * automatically added to the value specified here.
+ * ::WIMLIB_OPEN_FLAG_CHECK_INTEGRITY). Note: ::WIMLIB_OPEN_FLAG_SPLIT_OK
+ * is automatically added to the value specified here.
* @param wim_write_flags
* Bitwise OR of relevant flags prefixed with WIMLIB_WRITE_FLAG, which will
* be used to write the joined WIM.
} else if (template_lte && wim_resource_size(template_lte)) {
return false;
}
-
}
/* All right, barring a full checksum and given that the inodes share a
* useful stream information (e.g. checksums) from @template_inode.
*
* This assumes that the streams for @inode have been resolved (to point
- * directly to the appropriate `struct wim_lookup_table_entry') but do not
+ * directly to the appropriate `struct wim_lookup_table_entry's) but do not
* necessarily have checksum information filled in.
*/
static int
ctx->no_security_descriptors++;
break;
}
+ SetLastError(err);
goto error;
}
ret = 0;
HANDLE
win32_open_existing_file(const wchar_t *path, DWORD dwDesiredAccess)
{
- return CreateFileW(path,
- dwDesiredAccess,
- FILE_SHARE_READ,
- NULL, /* lpSecurityAttributes */
- OPEN_EXISTING,
- FILE_FLAG_BACKUP_SEMANTICS |
- FILE_FLAG_OPEN_REPARSE_POINT,
- NULL /* hTemplateFile */);
+ return CreateFile(path,
+ dwDesiredAccess,
+ FILE_SHARE_READ,
+ NULL, /* lpSecurityAttributes */
+ OPEN_EXISTING,
+ FILE_FLAG_BACKUP_SEMANTICS |
+ FILE_FLAG_OPEN_REPARSE_POINT,
+ NULL /* hTemplateFile */);
}
/* Pointers to functions that are not available on all targetted versions of