]> wimlib.net Git - wimlib/commitdiff
Code and docs cleanup
authorEric Biggers <ebiggers3@gmail.com>
Sat, 16 Mar 2013 21:13:13 +0000 (16:13 -0500)
committerEric Biggers <ebiggers3@gmail.com>
Sat, 16 Mar 2013 21:13:13 +0000 (16:13 -0500)
12 files changed:
Makefile.am
README.WINDOWS
configure.ac
doc/imagex-apply.1.in
doc/imagex-capture.1.in
doc/imagex-mount.1.in
doc/imagex.1.in
programs/imagex.c
programs/mkwinpeimg
src/add_image.c
src/extract_image.c
src/write.c

index 84360b3a8629996864a1e9224dfb75880fa04559..70f42876d349da42ae6ddf50804693aae751ea19 100644 (file)
@@ -159,7 +159,7 @@ if WINDOWS_BUILD
 TESTS =
 else
 # TODO: The tests need to be re-written for Windows builds.  One issue (that
-# applies to both test-imagex and test-imagex-capture_and_apply.) is that
+# applies to both test-imagex and test-imagex-capture_and_apply) is that
 # Cygwin's 'ln -s' will create some sort of regular file with special contents
 # rather than a reparse point.
 TESTS = $(dist_check_SCRIPTS)
index a0521f023e394f4245e3af38a8ab40fec3cf4562..952cbd85cf1ae239fbe2de95b1ec18074ae81d98 100644 (file)
@@ -8,18 +8,16 @@ Windows support currently has the following limitations:
 
 -  It relies on the Cygwin UNIX-compatibility layer.  You do not, however, need
    to have the Cygwin distribution installed to run it, as I have posted a ZIP
-   file on SourceForge that contains the build of wimlib along with the DLLs
-   needed for it to run.  Please note that these DLLs are free and open source
-   software; see http://www.cygwin.com/ for more details.
+   file on SourceForge that contains the build of wimlib and "imagex" along with
+   the DLLs needed for it to run.  Please note that these DLLs are free and open
+   source software; see http://www.cygwin.com/ for more details.
 
--  Mounting WIM files is not supported.  On Windows there is no equivalent of
-   FUSE, which I used to get mounting working on Linux and BSD, so I would have
-   to program a "Filesystem Filter" driver with Microsoft's eccentric API.
+-  Mounting WIM files is not supported.
 
 -  wimlib's API is not compatible with Microsoft's WIMGAPI, although they offer
    some of the same functionality.
 
-So to be clear:
+So, in terms of the "imagex" program:
 
 "imagex capture", "imagex append", and "imagex apply" will work on Windows and
 have the added advantage of saving and restoring alternate data streams,
index cb41ba188f8061243763e41ab5da6f119fb77f96..1b90c4851cb0d74eb9740c93c2a6dc3387a74f09 100644 (file)
@@ -176,8 +176,8 @@ case "$host" in
                dnl -no-undefined is needed to build a DLL in a Cygwin environment.
                CYGWIN_EXTRA_LDFLAGS="-no-undefined"
 
-               dnl -fvisibility=hidden should not be used in a Cygwin
-               dnl  environment
+               dnl -fvisibility=hidden should not be used when building PE
+               dnl binaries on Windows
                VISIBILITY_CFLAGS=""
 
                WITH_NTFS_3G_DEFAULT="no"
index d60c53d64acbc6386c92b1fca3e2b9e61086b81b..86b47f3d329cedb74775d2ddb8f45ff3816757f4 100644 (file)
@@ -197,23 +197,24 @@ imagex apply mywim.swm 1 dir --ref="mywim*.swm"
 
 This section documents the differences between \fBimagex apply\fR in the Windows
 builds of wimlib versus the rest of this man page, which is written to document
-UNIX version.
+the UNIX build.
 
 \fBimagex apply\fR does not have separate "normal" and "NTFS" modes on Windows.
 There is simply one mode, and it uses the Windows API to apply 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 apply the WIM image to any directory, not just an
-entire NTFS volume.  This is mostly the same behavior as Microsoft's ImageX.
+entire NTFS volume.  This is essentially the same behavior as Microsoft's
+ImageX.
 
 \fB--hardlink\fR, \fB--symlink\fR, and \fB--unix-data\fR are not supported on
 Windows.
 
-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.
+Except for the differences documented in this section, the Windows build of
+\fBimagex apply\fR should be essentially equivalent to the UNIX build.  However,
+one additional thing to note is that wimlib's Windows ImageX is NOT written to
+be command-line compatible with Microsoft's ImageX, although they are very
+similar.
 
 .SH OPTIONS
 .TP 6
@@ -257,9 +258,9 @@ the WIM file.  It is an error if the message digests don't match.  It's also
 considered to be an error if any WIM resources cannot be found in the stream
 lookup table.  So you can be fairly certain that the file streams are extracted
 correctly, even though \fBimagex apply\fR don't have a \fB/verify\fR option like
-Microsoft's version of imagex does.  Please note that this is separate from the
-integrity table of the WIM, which provides SHA1 message digests over raw chunks
-of the entire WIM file and is checked separately if the \fB--check\fR option is
+Microsoft's ImageX does.  Please note that this is separate from the integrity
+table of the WIM, which provides SHA1 message digests over raw chunks of the
+entire WIM file and is checked separately if the \fB--check\fR option is
 specified.
 
 You cannot use \fBimagex apply\fR to apply a WIM from a pipe (such as standard
index 38c462aa1460f7f2c84cb4c9fa336e1327a3555c..b306cbfad74d2b475350919999a6426114b80fdc 100644 (file)
@@ -113,24 +113,24 @@ multiple files or directories to be incorporated into a WIM image using a single
 
 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.
+page, which is written to document UNIX build.
 
 \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.
+directory, not just an entire NTFS volume.  This is essentially 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.
+Except for the differences documented in this section, the Windows build of
+\fBimagex capture\fR and \fBimagex append\fR should be essentially equivalent to
+the UNIX build.  However, one additional thing to note is that wimlib's Windows
+ImageX is NOT written to be command-line compatible with Microsoft's ImageX,
+although they are very similar.
 
 .SH OPTIONS
 .TP 6
@@ -235,7 +235,7 @@ UNIX.  Microsoft's software will not understand this special
 information.
 .TP
 \fB--source-list\fR
-\fBimagex capture\fR and \fBimagex append\fR, as of wimlib 1.2.7, support a new
+\fBimagex capture\fR and \fBimagex append\fR, as of wimlib 1.3.0, support a new
 option to create a WIM image from multiple files or directories.  When
 \fB--source-list\fR is specified, the \fISOURCE\fR argument specifies the name
 of a text file, each line of which is either 1 or 2 whitespace separated
@@ -266,7 +266,7 @@ overlay     /overlay
 
 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.
+if the same file appears in different overlays to the same directory.
 
 Filenames containing whitespace may be quoted with either single quotes or
 double quotes.  Quotes may not be escaped.
index 0844e4a4dd432c31c646ef3bb6dd50d5d73a76bc..86a60dd971ed3c1cbf0927c16404d7f8497e6694 100644 (file)
@@ -63,8 +63,7 @@ imagex mount mywim.swm 1 dir --ref="mywim*.swm"
 
 If wimlib was configured using the \fB--without-fuse\fR flag, then the \fBimagex
 mount\fR, \fBimagex mountrw\fR, and \fBimagex unmount\fR commands will not work.
-Also, these commands are not available in the experimental Windows builds of
-wimlib.
+Also, these commands are not available in the Windows builds of wimlib.
 
 You can mount multiple images from a WIM file read-only at the same time, but
 you can only mount one image at a time from a WIM read-write.
index 7afbbd4830888541279dfba821bd0884f00018d4..9e01c800bb111b96cb9ddc23ec5c7cca066cf5f8 100644 (file)
@@ -93,9 +93,8 @@ application modes (although the \fBimagex\fR subcommands for the modes are the
 same): one for general image capture and application, and one for the capture or
 application of an image specifically from/to an NTFS volume.
 
-Note: the above applies to UNIX builds.  On the experimental Windows builds of
-wimlib, there is only one image capture and application mode, similar to
-Microsoft's ImageX.
+Note: the above applies to UNIX builds.  On the Windows builds of wimlib, there
+is only one image capture and application mode, similar to Microsoft's ImageX.
 
 .IP \[bu]
 Microsoft's version has some weird limitations, like it won't let you extract a
@@ -136,7 +135,8 @@ create compressed WIM files.
 
 .IP \[bu]
 wimlib's \fBimagex capture\fR supports a special mode where UNIX file modes,
-owners, and groups are stored.
+owners, and groups are stored.  (Note: this functionality is only available on
+UNIX builds.)
 
 .IP \[bu]
 wimlib's \fBimagex mount\fR and \fBimagex mountrw\fR are much faster than
index b16579e74090782e7a50052dea7a02d563ce9cc6..f635e08613ec9e2447db625f41372784e301ab08 100644 (file)
@@ -348,7 +348,7 @@ enum {
 /*
  * Parses a filename in the source list file format.  (See the man page for
  * 'imagex capture' for details on this format and the meaning.)  Accepted
- * formats for filenames are an unquoted string, whitespace-delimited, or a
+ * formats for filenames are an unquoted string (whitespace-delimited), or a
  * double or single-quoted string.
  *
  * @line_p:  Pointer to the pointer to the line of data.  Will be updated
@@ -494,7 +494,9 @@ parse_source_list(char *source_list_contents, size_t source_list_nbytes,
        p = source_list_contents;
        j = 0;
        for (i = 0; i < nlines; i++) {
-               char *endp = strchr(p, '\n');
+               /* XXX: Could use rawmemchr() here instead, but it may not be
+                * available on all platforms. */
+               char *endp = memchr(p, '\n', source_list_nbytes);
                size_t len = endp - p + 1;
                *endp = '\0';
                if (!is_comment_line(p, len)) {
index d44e2b0fce0a6692a7d085407b46650c8723ab9a..b5b9976919b9c5f1b8dfe2404430c5548617545f 100755 (executable)
@@ -3,7 +3,7 @@
 # This script can make a customized bootable image of Windows PE.
 #
 
-# Copyright (C) 2012 Eric Biggers
+# Copyright (C) 2012, 2013 Eric Biggers
 #
 # This program is free software: you can redistribute it and/or modify
 # it under the terms of the GNU General Public License as published by
@@ -20,7 +20,7 @@
 
 script_name="$(basename $0)"
 PREFIX_REG="::"
-WIMLIB_VERSION=1.2.7
+WIMLIB_VERSION=1.3.0
 
 calc_columns () {
        STAT_COL=80
index 7a8609fb7084c21656cb5ac2e54a76f356cae3e3..5b51f493ea78e597375259ee7345be6222ae98ea 100644 (file)
@@ -201,7 +201,7 @@ static int win32_recurse_directory(struct wim_dentry *root,
 
        {
                /* Begin reading the directory by calling FindFirstFileW.
-                * Unlink UNIX opendir(), FindFirstFileW has file globbing built
+                * Unlike UNIX opendir(), FindFirstFileW has file globbing built
                 * into it.  But this isn't what we actually want, so just add a
                 * dummy glob to get all entries. */
                wchar_t pattern_buf[path_utf16_nchars + 3];
@@ -449,7 +449,7 @@ static int win32_capture_stream(const wchar_t *path_utf16,
                 * message digest */
                lte->refcnt++;
        } else {
-               /* Make a new new wim_lookup_table_entry */
+               /* Make a new wim_lookup_table_entry */
                lte = new_lookup_table_entry();
                if (!lte) {
                        ret = WIMLIB_ERR_NOMEM;
@@ -856,7 +856,7 @@ static int build_dentry_tree(struct wim_dentry **root_ret,
                ERROR("Win32 API: Failed to open \"%s\"", root_disk_path);
                win32_error(err);
                ret = WIMLIB_ERR_OPEN;
-               goto out_free_path_utf16;
+               goto out_destroy_sd_set;
        }
 
        BY_HANDLE_FILE_INFORMATION file_info;
@@ -1194,7 +1194,7 @@ static const char *canonicalize_target_path(char *target_path)
 {
        char *p;
        if (target_path == NULL)
-               target_path = "";
+               return "";
        for (;;) {
                if (*target_path == '\0')
                        return target_path;
@@ -1254,7 +1254,7 @@ static int capture_source_cmp(const void *p1, const void *p2)
  * after leading and trailing forward slashes are stripped.
  *
  * One purpose of this is to make sure that target paths that are inside other
- * target paths are extracted after the containing target paths. */
+ * target paths are added after the containing target paths. */
 static void sort_sources(struct wimlib_capture_source *sources,
                         size_t num_sources)
 {
@@ -1537,8 +1537,10 @@ WIMLIBAPI int wimlib_add_image_multisource(WIMStruct *w,
        DEBUG("Building dentry tree.");
        if (num_sources == 0) {
                root_dentry = new_filler_directory("");
-               if (!root_dentry)
+               if (!root_dentry) {
+                       ret = WIMLIB_ERR_NOMEM;
                        goto out_free_security_data;
+               }
        } else {
                size_t i;
 
index 25f4d917450ece86f753d1c3d20828e359f0f985..b66949e6fdbbeaa71be4e5f5c701e8ddc3db8e09 100644 (file)
@@ -169,19 +169,19 @@ static int win32_extract_stream(const struct wim_inode *inode,
                /* Named stream.  Create a buffer that contains the UTF-16LE
                 * string [./]@path:@stream_name_utf16.  This is needed to
                 * create and open the stream using CreateFileW().  I'm not
-                * aware of any other APIs to do this.  Note: note that the
-                * '$DATA' suffix seems to be unneeded; Additional note: a "./"
-                * prefix needs to be added when the path is not absolute to
-                * avoid ambiguity with drive letters. */
+                * aware of any other APIs to do this.  Note: the '$DATA' suffix
+                * seems to be unneeded.  Additional note: a "./" prefix needs
+                * to be added when the path is not absolute to avoid ambiguity
+                * with drive letters. */
                size_t stream_path_nchars;
                size_t path_nchars;
                size_t stream_name_nchars;
                const wchar_t *prefix;
 
-               path_nchars = wcslen(path);
+               path_nchars = wcslen(path);
                stream_name_nchars = wcslen(stream_name_utf16);
                stream_path_nchars = path_nchars + 1 + stream_name_nchars;
-               if (path[0] != L'/' && path[1] != L'\\') {
+               if (path[0] != L'/' && path[0] != L'\\') {
                        prefix = L"./";
                        stream_path_nchars += 2;
                } else {
@@ -191,8 +191,8 @@ static int win32_extract_stream(const struct wim_inode *inode,
                swprintf(stream_path, stream_path_nchars + 1, L"%ls%ls:%ls",
                         prefix, path, stream_name_utf16);
        } else {
-               /* Unnamed stream; it's path is just the path to the file
-                * itself. */
+               /* Unnamed stream; its path is just the path to the file itself.
+                * */
                stream_path = (wchar_t*)path;
 
                /* Directories must be created with CreateDirectoryW().  Then
@@ -203,7 +203,7 @@ static int win32_extract_stream(const struct wim_inode *inode,
                                err = GetLastError();
                                if (err != ERROR_ALREADY_EXISTS) {
                                        ERROR("Failed to create directory \"%ls\"",
-                                             path);
+                                             stream_path);
                                        win32_error(err);
                                        ret = WIMLIB_ERR_MKDIR;
                                        goto fail;
@@ -324,7 +324,6 @@ out:
  * @inode:     The WIM inode that was extracted and has a security descriptor.
  * @path:      UTF-16LE external path that the inode was extracted to.
  * @sd:                Security data for the WIM image.
- * @path_utf8:  @path in UTF-8 for error messages only.
  *
  * Returns 0 on success; nonzero on failure.
  */
index 131125fa5881ac6500e6bd9a2a6e6cd47accef9c..4e59b851ae2a17aafc04799eecfe4b02c7d11fc1 100644 (file)
@@ -259,7 +259,7 @@ static int prepare_resource_for_read(struct wim_lookup_table_entry *lte
 {
        switch (lte->resource_location) {
        case RESOURCE_IN_FILE_ON_DISK:
-               if (!lte->file_on_disk_fp) {
+               if (!lte->file_on_disk_fp) {
                        lte->file_on_disk_fp = fopen(lte->file_on_disk, "rb");
                        if (!lte->file_on_disk_fp) {
                                ERROR_WITH_ERRNO("Failed to open the file "