]> wimlib.net Git - wimlib/blobdiff - doc/imagex.1.in
Split WIM mount and split WIM documentation
[wimlib] / doc / imagex.1.in
index 7fee130d3228208c741c7f03177b2f29e9c22884..263b2c964849a37076674d30f721d09bd201d088 100644 (file)
@@ -1,4 +1,4 @@
-.TH IMAGEX 1 "May 2012" "imagex (wimlib @VERSION@)" "User Commands"
+.TH IMAGEX 1 "September 2012" "imagex (wimlib @VERSION@)" "User Commands"
 .SH NAME
 imagex \- Create, modify, extract, mount, or unmount a WIM (Windows Imaging Format) archive
 .SH SYNOPSIS
@@ -32,7 +32,7 @@ files). Its interface is meant to be similar to Microsoft's imagex.exe program.
 
 To do its work, \fBimagex\fR uses \fBwimlib\fR, a library which provides
 interfaces for manipulating WIM archives.  You could wimlib in your own programs
-if you wanted to.  Wimlib's public interface is documented.
+if you wanted to.  wimlib's public interface is documented.
 
 See \fBWARNING\fR.
 
@@ -44,94 +44,81 @@ There is a separate manual page for each \fBimagex\fR command.
 
 The following features are currently supported:
 
-.IP \[bu] 2
-Mount an image in a WIM read-only (\fBimagex mount\fR)
-.IP \[bu] 2
-Mount an image in a WIM read-write (\fBimagex mountrw\fR)
-.IP \[bu] 2
-Create a WIM from a directory (\fBimagex capture\fR)
-.IP \[bu] 2
-Append a directory onto a WIM as a new image (\fBimagex append\fR)
-.IP \[bu] 2
-Delete image(s) from a WIM (\fBimagex delete\fR)
-.IP \[bu] 2
-Export image(s) from a WIM (\fBimagex export\fR)
-.IP \[bu] 2
+.IP \[bu] 3
+Create a stand-alone WIM from a directory or NTFS volume (\fBimagex capture\fR)
+.IP \[bu]
+Append a directory or NTFS volume onto a stand-alone WIM as a new image (\fBimagex
+append\fR)
+.IP \[bu]
+Apply an image from a stand-alone or split WIM to a directory or NTFS volume
+(\fBimagex apply\fR)
+.IP \[bu]
+Mount an image from a stand-alone or split WIM read-only (\fBimagex mount\fR)
+.IP \[bu]
+Mount an image from a stand-alone WIM read-write (\fBimagex mountrw\fR)
+.IP \[bu]
+Delete image(s) from a stand-alone WIM (\fBimagex delete\fR)
+.IP \[bu]
+Export image(s) from a stand-alone WIM (\fBimagex export\fR)
+.IP \[bu]
 Display information about a WIM file (\fBimagex info\fR, \fBimagex dir\fR)
-.IP \[bu] 2
+.IP \[bu]
 Change the name or description of an image in the WIM (\fBimagex info\fR)
-.IP \[bu] 2
+.IP \[bu]
 Change which image in a WIM is bootable (\fBimagex info\fR)
-.IP \[bu] 2
-Combining split WIMs into one WIM (\fBimage join\fR)
-.IP \[bu] 2
-Splitting a WIM into multiple parts (\fBimage split\fR)
-.IP \[bu] 2
+.IP \[bu]
+Combine split WIMs into one stand-alone WIM (\fBimage join\fR)
+.IP \[bu]
+Split a stand-alone WIM into multiple parts (\fBimage split\fR)
+.IP \[bu]
 Support for all WIM compression types, both compression and decompression (LZX,
 XPRESS, and none)
-.IP \[bu] 2
-Integrity table
-.IP \[bu] 2
-XML data (parsed and written using \fBlibxml\fR(3))
+.IP \[bu]
+WIM integrity table is supported (\fB--check\fR option to many commands)
+.IP \[bu]
+WIM XML data (parsed and written using \fBlibxml\fR(3))
 
 .SH UNSUPPORTED FEATURES
-The following features are currently unsupported:
-.IP \[bu] 2
-Wimlib cannot add security data when it captures a WIM file, although it will
-preserve security data for existing WIM files.  New files added to a mounted
-WIM will be added without security data.  This does not seem to matter for
-Windows PE, but this means that you should not use this program to image a drive
-containing Windows Vista/7/8 and expect it to be applied with the correct file
-permissions.
-.IP \[bu] 2
-Alternate file streams are unsupported and will be lost when wimlib writes a WIM
-file.  Note that you shouldn't really have these on your Windows system anyway
-because they are unneeded and a security risk.
-.IP \[bu] 2
-Directly applying or mounting split WIMs is unsupported.  You have to combine
-them together with \fBimagex join\fR first.
-.IP \[bu] 2
-The \fB--verify\fR option, for all commands that use it is unsupported.  Without
-this option, there theoretically could be a SHA1 hash collision between two
-files, although it's very unlikely.  You can still verify a WIM manually by
-capturing it, then applying it to a different location, then running a recursive
-diff on the two directory trees.
-.IP \[bu] 2
-The \fB--config\fR option, for all commands that use it.
-.IP \[bu] 2
-Different versions of the WIM file format (if different versions even exist).
-
-Also see the Doxygen documentation for Wimlib.
 
-.SH DIFFERENCES FROM MICROSOFT IMAGEX
+As of version 1.0.0, wimlib supports capturing and applying WIMs directly from
+NTFS and has much improved support for hard links and symbolic links.  In
+addition, you may now apply split WIMs and mount them read-only.  I don't think
+there are many other features that would be worth it to implement.  Besides
+porting the library to Windows (which I'm not really interested in), the main
+thing that could use improvement (in my opinion) is that the LZX compression
+ratio still isn't quite as good as Microsoft's version.  Also, exporting an
+image from a split WIM could be supported.  Furthermore, if Microsoft updates
+the WIM format, I'd need to support it, but it looks like the format for Windows
+8 is the same as that of Windows 7.
 
-See \fBUNSUPPORTED FEATURES\fR.
+.SH DIFFERENCES FROM MICROSOFT IMAGEX
 
-The most important difference is that this version of \fBimagex\fR cannot
-capture and restore Windows images losslessly because file permissions and
-alternate file streams cannot be captured.  This is because Microsoft designed
-the WIM format to be specific to their NTFS filesystem and the Windows security
-model/API, which is difficult to support in a non-Windows program.  However, you
-can still create images of Windows PE, even from a directory tree on a non-NTFS
-filesystem.
+While similar to Microsoft's "imagex.exe" program, this program is designed for
+UNIX-based systems and by the nature of the platform cannot be exactly the same
+as Microsoft's version.
 
-See the documentation for each subcommand of \fBimagex\fR; in some cases they do
-not do exactly the same thing as imagex.exe.
+In particular, because Microsoft designed the WIM file format to accomodate
+Windows-specific and NTFS-specific features, we must have two separate image
+capture and 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.
 
-Some features, such as the ability to keep files hard-linked when they are
-extracted from a WIM, are not available in Microsoft's version of imagex.
-Also, doesn't seem to be an equivalent of \fBimagex join\fR in Microsoft's
-version; you would have to use \fBimagex.exe /export\fR, but that doesn't let
-you export all images at once.
+Some features, such as the ability to keep files hard-linked across WIM images
+when they are extracted from a WIM, are not available in Microsoft's version of
+imagex.  Also, doesn't seem to be an equivalent of \fBimagex join\fR in
+Microsoft's version; you would have to use \fBimagex.exe /export\fR, but that
+doesn't let you export all images at once.  Furthermore, this version of
+\fBimagex\fR lets you mount an image from a split WIM read-only, while
+Microsoft's version does not.
 
 Microsoft's version has some weird limitations, like it won't let you extract a
 WIM on a shared folder, and it requires some commands to be run only from
 Windows PE and not from regular Windows.  This version does not have these
 unusual limitations, although it won't actually run on Windows anyway.
 
-The \fB/scroll\fR and \fB/log\fR switches from Microsoft's version of imagex
-will not be implemented.  Note that to scroll the output in the UNIX shell you
-can just pipe the output into \fBless\fR(1).
+There are bugs in Microsoft's WIM library and I obviously have not included
+these bugs in my version; however it's to be expected that despite that fact, my
+version has more bugs because it's been less widely tested and used.
 
 Obviously, this version of imagex is free software but Microsoft's version is
 not.