]> wimlib.net Git - wimlib/blobdiff - doc/imagex.1.in
More documentation updates
[wimlib] / doc / imagex.1.in
index 7fee130d3228208c741c7f03177b2f29e9c22884..1352ce77a489e9ad83c8394930e37cd8c44b2aa6 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
 .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
 
 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.
 
 
 See \fBWARNING\fR.
 
@@ -49,9 +49,10 @@ 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
 .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)
+Create a WIM from a directory or NTFS volume (\fBimagex capture\fR)
 .IP \[bu] 2
 .IP \[bu] 2
-Append a directory onto a WIM as a new image (\fBimagex append\fR)
+Append a directory or NTFS volume 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
 .IP \[bu] 2
 Delete image(s) from a WIM (\fBimagex delete\fR)
 .IP \[bu] 2
@@ -63,9 +64,9 @@ Change the name or description of an image in the WIM (\fBimagex info\fR)
 .IP \[bu] 2
 Change which image in a WIM is bootable (\fBimagex info\fR)
 .IP \[bu] 2
 .IP \[bu] 2
 Change which image in a WIM is bootable (\fBimagex info\fR)
 .IP \[bu] 2
-Combining split WIMs into one WIM (\fBimage join\fR)
+Combine split WIMs into one WIM (\fBimage join\fR)
 .IP \[bu] 2
 .IP \[bu] 2
-Splitting a WIM into multiple parts (\fBimage split\fR)
+Split a WIM into multiple parts (\fBimage split\fR)
 .IP \[bu] 2
 Support for all WIM compression types, both compression and decompression (LZX,
 XPRESS, and none)
 .IP \[bu] 2
 Support for all WIM compression types, both compression and decompression (LZX,
 XPRESS, and none)
@@ -75,63 +76,41 @@ Integrity table
 XML data (parsed and written using \fBlibxml\fR(3))
 
 .SH UNSUPPORTED FEATURES
 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.
+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.  I don't
+think there are many other features that would be worth it to implement; the
+only significant thing missing (in my opinion) is that split WIMs need to be
+handled better (e.g. it should be possible to apply a split WIM using \fBimagex
+apply\fR).  And 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.
 
 .SH DIFFERENCES FROM MICROSOFT IMAGEX
 
 
 .SH DIFFERENCES FROM MICROSOFT IMAGEX
 
-See \fBUNSUPPORTED FEATURES\fR.
-
-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.
 
 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.
 
 
 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.
 
 Obviously, this version of imagex is free software but Microsoft's version is
 not.