]> wimlib.net Git - wimlib/blobdiff - doc/man1/wimlib-imagex-capture.1
Character encoding and string conversion updates
[wimlib] / doc / man1 / wimlib-imagex-capture.1
index 05197006d0083fa069c02f75df67a09a138ef4f8..bd4f42bd7aa84904d9cfd22cf52d1c03351fe313 100644 (file)
@@ -1,4 +1,4 @@
-.TH WIMLIB-IMAGEX "1" "November 2015" "wimlib 1.8.3" "User Commands"
+.TH WIMLIB-IMAGEX "1" "June 2016" "wimlib 1.9.2" "User Commands"
 .SH NAME
 wimlib-imagex-capture, wimlib-imagex-append \- Create or append a WIM image
 .SH SYNOPSIS
@@ -72,6 +72,12 @@ There is no support for storing extended attributes (e.g. SELinux security
 labels and POSIX ACLs).  Also note that last status change times (ctime) are not
 stored.
 .PP
+Filenames and symbolic link targets on UNIX filesystems which are not valid
+UTF-8 with the addition of surrogate codepoints are unsupported.  Note: if you
+have a filesystem containing filenames in another multibyte encoding, such as
+ISO-8859-1, and you wish to archive it with wimlib, you may be able to mount it
+with an option which causes its filenames to be presented as UTF-8.
+.PP
 Pedantic note: A limitation of the WIM format prevents the unusual case where a
 single symbolic link file itself has multiple names (hard links); in this
 unlikely case, each symbolic link is stored as an independent file.
@@ -109,6 +115,8 @@ DOS/Windows file attribute flags.
 .IP \[bu]
 All names of all files, including names in the Win32 namespace, DOS namespace,
 Win32+DOS namespace, and POSIX namespace.  This includes hard links.
+.IP \[bu]
+Object IDs.
 .PP
 However, the main limitations of this NTFS volume capture mode are:
 .IP \[bu] 4
@@ -158,8 +166,10 @@ DOS names (8.3) names of files; however, the failure to read them is not
 considered an error condition.
 .IP \[bu]
 Hard links, if supported by the source filesystem.
+.IP \[bu]
+Object IDs, if supported by the source filesystem.
 .PP
-There is no support for storing NTFS extended attributes and object IDs.
+There is no support for storing NTFS extended attributes.
 .PP
 The capture process is reversible, since when \fBwimlib-imagex apply\fR (on
 Windows) extracts the captured WIM image, it will extract all of the above
@@ -357,7 +367,7 @@ that may be present on the filesystem.
 .TP
 \fB--unix-data\fR
 (UNIX-like systems only) Store the UNIX owner, group, mode, and device ID (major
-and minor number) of each captured file.  As of wimlib v1.7.0, you can backup
+and minor number) of each captured file.  Since wimlib v1.7.0, you can backup
 and restore not only the standard UNIX file permission information, but also
 character device nodes, block device nodes, named pipes (FIFOs), and UNIX domain
 sockets.
@@ -498,7 +508,7 @@ When this option is provided, the capture or append of the new image will be
 optimized by not reading files that, based on metadata such as timestamps,
 appear not to have been modified since they were archived in the existing
 \fIIMAGE\fR.  Barring manipulation of timestamps, this option only affects
-performance and does not change the resulting WIM image.
+performance and does not change the resulting WIM image (but see note below).
 .IP ""
 As shown, the full syntax for the argument to this option is to specify the WIM
 file, a colon, and the image; for example, "--update-of mywim.wim:1".  However,
@@ -506,6 +516,21 @@ the WIM file and colon may be omitted, in which case the WIM file will default
 to the WIM file being appended to for append operations, or the WIM file from
 which a delta is being taken (only if \fB--delta-from\fR is specified exactly
 once) for capture operations.
+.IP ""
+Note: in the Windows version of wimlib, it has been observed that
+\fB--update-of\fR mode is not completely reliable at detecting changes in file
+contents, sometimes causing the old contents of a few files to be archived
+rather than the current contents.  The cause of this problem is that Windows
+does not immediately update a file's last modification timestamp after every
+write to that file.  Unfortunately, there is no known way for applications like
+wimlib to automatically work around this bug.  Manual workarounds are possible;
+theoretically, taking any action that causes the problematic files to be closed,
+such as restarting applications or the computer itself, should cause the files'
+last modification timestamps to be updated.  Also note that wimlib compares file
+sizes as well as timestamps in determining whether a file has changed, which
+helps make the problem less likely to occur; and the problem does not occur on
+other operating systems such as Linux which maintain files' last modification
+timestamps correctly.
 .TP
 \fB--delta-from\fR=\fIWIMFILE\fR
 For \fBwimlib-imagex capture\fR only: capture the new WIM as a "delta" from
@@ -575,14 +600,18 @@ default, set the configuration file to
 however, this may still be overridden through the \fB--config\fR parameter.
 .TP
 \fB--unsafe-compact\fR
-See the documentation for this option in \fBwimlib-imagex-optimize\fR (1).
+For \fBwimlib-imagex append\fR: compact the WIM archive in-place and append any
+new data, eliminating "holes".  In general, this option should \fInot\fR be used
+because a failed or interrupted compaction will corrupt the WIM archive.  For
+more information, see the documentation for this option in
+\fBwimlib-imagex-optimize\fR (1).
 .TP
 \fB--snapshot\fR
-EXPERIMENTAL: create a temporary filesystem snapshot of the source directory and
-capture the files from it.  Currently, this option is only supported on Windows,
-where it uses the Volume Shadow Copy Service (VSS).  Using this option, you can
-create a consistent backup of the system volume of a running Windows system
-without running into problems with locked files.  For the VSS snapshot to be
+Create a temporary filesystem snapshot of the source directory and capture the
+files from it.  Currently, this option is only supported on Windows, where it
+uses the Volume Shadow Copy Service (VSS).  Using this option, you can create a
+consistent backup of the system volume of a running Windows system without
+running into problems with locked files.  For the VSS snapshot to be
 successfully created, \fBwimlib-imagex\fR must be run as an Administrator, and
 it cannot be run in WoW64 mode (i.e. if Windows is 64-bit, then
 \fBwimlib-imagex\fR must be 64-bit as well).