wimlib-imagex documentation updates
[wimlib] / doc / imagex-apply.1.in
1 .TH WIMLIB-IMAGEX "1" "August 2013" "@IMAGEX_PROGNAME@ @VERSION@" "User Commands"
2 .SH NAME
3 @IMAGEX_PROGNAME@-apply \- Extract one image, or all images, from a WIM archive
4 .SH SYNOPSIS
5 \fB@IMAGEX_PROGNAME@ apply\fR \fIWIMFILE\fR [\fIIMAGE\fR] \fITARGET\fR [\fIOPTION\fR...]
6 .SH DESCRIPTION
7 \fB@IMAGEX_PROGNAME@ apply\fR extracts an image, or all images, from the Windows
8 Imaging (WIM) file \fIWIMFILE\fR.  This command is also available as simply
9 \fBwimapply\fR if the appropriate hard link or batch file has been installed.
10 .PP
11 This command is designed to extract, or "apply", one or more full WIM images.
12 If you instead want to extract only certain files or directories contained in a
13 WIM image, consider using \fB@IMAGEX_PROGNAME@ extract\fR or
14 \fB@IMAGEX_PROGNAME@ mount\fR instead.
15 .PP
16 \fIIMAGE\fR specifies the WIM image in \fIWIMFILE\fR to extract.  It may be a
17 1-based index of an image in \fIWIMFILE\fR, the name of an image in
18 \fIWIMFILE\fR, or the keyword "all" to indicate that all images in \fIWIMFILE\fR
19 are to be extracted.  Use the \fB@IMAGEX_PROGNAME@ info\fR (1) command to show
20 what images a WIM file contains.  \fIIMAGE\fR may be omitted if \fIWIMFILE\fR
21 contains only one image.
22 .PP
23 \fITARGET\fR specifies where to extract the WIM image to.  If \fITARGET\fR
24 specifies a directory, the WIM image is extracted to that directory (see
25 \fBDIRECTORY EXTRACTION (UNIX)\fR or \fBDIRECTORY EXTRACTION (WINDOWS)\fR).
26 Similarly, if \fITARGET\fR specifies a non-existent file, a directory is created
27 in that location and the WIM image is extracted to that directory.
28 .PP
29 If \fIIMAGE\fR is specified as "all", then all the images in \fIWIMFILE\fR are
30 actually extracted into subdirectories of \fITARGET\fR, each of which is given
31 the name of the corresponding image, falling back to the image index in the case
32 of an image with no name or a name not valid as a filename.
33 .PP
34 Alternatively, on UNIX-like systems only, if \fITARGET\fR specifies a regular
35 file or block device, it is interpreted as an NTFS volume to which the WIM image
36 is to be extracted (see \fBNTFS VOLUME EXTRACTION (UNIX)\fR).  Only a single
37 image can be extracted in this mode, and only extracting to the root of the NTFS
38 volume (not a subdirectory thereof) is supported.
39 .PP
40 \fIWIMFILE\fR may be "-" to read the WIM from standard input rather than from a
41 file, but see \fBPIPABLE WIMS\fR for more information.
42 .PP
43 \fB@IMAGEX_PROGNAME@ apply\fR supports applying images from stand-alone WIMs as
44 well as split WIMs.  See \fBSPLIT WIMS\fR.
45 .SH DIRECTORY EXTRACTION (UNIX)
46 This section documents how \fB@IMAGEX_PROGNAME@ apply\fR (and also
47 \fB@IMAGEX_PROGNAME@ extract\fR) extract a WIM image (or a possibly a subset
48 thereof, in the case of \fB@IMAGEX_PROGNAME@ extract\fR) to a directory on
49 UNIX-like systems.  See \fBDIRECTORY EXTRACTION (WINDOWS)\fR for the
50 corresponding documentation for Windows.
51
52 As mentioned, a WIM image can be applied to a directory on a UNIX-like system by
53 providing a \fITARGET\fR directory.  However, it is important to keep in mind
54 that the WIM format was designed for Windows, and as a result WIM files can
55 contain data or metadata that cannot be represented on UNIX-like systems.  The
56 main information that \fB@IMAGEX_PROGNAME@\fR will \fInot\fR be able to extract
57 on UNIX-like systems is the following:
58 .IP \[bu] 4
59 Windows security descriptors (which include the file owner, group, and ACLs).
60 .IP \[bu]
61 Named data streams.
62 .IP \[bu]
63 Reparse points other than symbolic links and junction points.
64 .IP \[bu]
65 Certain file attributes such as compression, encryption, and sparseness.
66 .IP \[bu]
67 Short (DOS) names for files.
68 .IP \[bu]
69 File creation timestamps.
70 .PP
71 Notes: Unsupported data and metadata is simply not extracted, but
72 \fB@IMAGEX_PROGNAME@\fR always warns you when the contents of the WIM image
73 can't be exactly represented when extracted.  Last access and last modification
74 timestamps are specified to 100 nanosecond granularity in the WIM file, but will
75 only be extracted to the highest precision supported by the underlying operating
76 system, C library, and filesystem.
77 .SH NTFS VOLUME EXTRACTION (UNIX)
78 This section documents how \fB@IMAGEX_PROGNAME@ apply\fR extracts a WIM image
79 directly to an NTFS volume image on UNIX-like systems.  See \fBDIRECTORY EXTRACTION
80 (WINDOWS)\fR for the corresponding documentation for Windows.
81 .PP
82 As mentioned, \fB@IMAGEX_PROGNAME@\fR running on a UNIX-like system can apply a
83 WIM image directly to an NTFS volume by specifying \fITARGET\fR as a regular file
84 or block device containing an NTFS filesystem.  The NTFS filesystem need not be
85 empty, although it's expected that it be empty for the intended use cases.  A
86 new NTFS filesystem can be created using the \fBmkntfs\fR(8) command provided
87 with \fBntfs-3g\fR.
88 .PP
89 In this NTFS volume extraction mode, the WIM image is extracted to the root of
90 the NTFS volume in a way preserves almost all information contained in the WIM
91 image.  It therefore does not suffer from the limitations described in
92 \fBDIRECTORY EXTRACTION (UNIX)\fR.  This support relies on libntfs-3g to write
93 to the NTFS volume and handle NTFS-specific and Windows-specific data.
94 .PP
95 Please note that this NTFS volume extraction mode is \fInot\fR entered if
96 \fITARGET\fR is a directory, even if an NTFS filesystem is mounted on
97 \fITARGET\fR.  You must specify the NTFS volume itself (and it must be
98 unmounted, and you must have permission to write to it).
99 .PP
100 This NTFS volume extraction mode attempts to extract as much information as
101 possible, including:
102 .IP \[bu] 4
103 All data streams of all files, including the unnamed data stream as well as all
104 named data streams.
105 .IP \[bu]
106 Reparse points, including symbolic links, junction points, and other reparse
107 points.
108 .IP \[bu]
109 File and directory creation, access, and modification timestamps, using the
110 native NTFS resolution of 100 nanoseconds.
111 .IP \[bu]
112 Windows security descriptors, including all components (owner, group, DACL, and
113 SACL).
114 .IP \[bu]
115 DOS/Windows file attribute flags.
116 .IP \[bu]
117 All names of all files, including names in the Win32 namespace, DOS namespace,
118 Win32+DOS namespace, and POSIX namespace.  This includes hard links.
119 .PP
120 Currently, the only known limitation (in terms of exactly extracting all data
121 and metadata) is that the extraction of encrypted files is not expected to work
122 properly.
123 .PP
124 Since all (or almost all) information from the WIM image is restored in this
125 mode, it is possible to restore an image of an actual Windows installation using
126 \fB@IMAGEX_PROGNAME@\fR on UNIX-like systems in addition to with
127 \fB@IMAGEX_PROGNAME@\fR on Windows.  In the examples at the end of this manual
128 page, there is an example of applying an image from the "install.wim" file
129 contained in the installation media for Windows Vista, Windows 7, and Windows 8
130 in the "sources" directory.
131 .PP
132 But in order to actually boot Windows from an applied image, you must understand
133 the boot process of Windows versions Vista and later.  Basically, it is the
134 following:
135 .nr step 1 1
136 .IP \n[step]. 3
137 The Master Boot Record loads the Volume Boot Record (also called the Boot
138 Sector) of the active partition, which is on an NTFS filesystem.  This partition
139 is called the "system partition".
140 .IP \n+[step].
141 The "bootmgr" program on the "system partition" is loaded (\\BOOTMGR).
142 .IP \n+[step].
143 bootmgr loads the Boot Configuration Data (\\Boot\\BCD) from the "system
144 partition".
145 .IP \n+[step].
146 Based on the information contained in the Boot Configuration Data, a loader for
147 the Windows kernel is executed from the "Boot" partition, which is where Windows
148 is installed.
149 .PP
150 So let's say you applied an image from an existing "install.wim" as in the
151 example, or you've applied a custom Windows image that you've created using the
152 \fB@IMAGEX_PROGNAME@ capture\fR (1) command.  You've just applied the "Boot" partition, or
153 the main Windows partition, but there is no "System" partition yet (i.e.  no
154 \\BOOTMGR and no \\Boot\\BCD).
155 .PP
156 A "System" partition can be created created by running the "bcdboot.exe" program
157 from within Windows or Windows PE.  Alternatively, you can capture a separate
158 WIM image containing the "System" partition.  Or, the "System" partition may the
159 same as the "Boot" partition, so the two "partitions" may be combined in one WIM
160 image.  However, as the \\Boot\\BCD file contains the Windows bootloader
161 configuration, a WIM containing it can only be used on systems where you are
162 setting up the same bootloader configuration, including the same partition
163 layout.
164 .PP
165 Besides setting up the files on the "System" partition, don't forget to set the
166 bootable flag on it, and have a master boot record that loads the bootable
167 partition (Windows' MBR does, and SYSLINUX provides an equivalent MBR).
168 .SH DIRECTORY EXTRACTION (WINDOWS)
169 On Windows, \fB@IMAGEX_PROGNAME@ apply\fR and \fB@IMAGEX_PROGNAME@ extract\fR
170 natively support Windows-specific and NTFS-specific data.  For best results, the
171 target directory should be located on an NTFS volume and \fB@IMAGEX_PROGNAME@\fR
172 should be run with Administrator privileges; however, non-NTFS filesystems and
173 running without Administrator privileges are also supported.
174 .PP
175 On Windows, \fB@IMAGEX_PROGNAME@ apply\fR and \fB@IMAGEX_PROGNAME@ extract\fR
176 try to extract as much data and metadata as possible, including:
177 .IP \[bu] 4
178 All data streams of all files.  This includes the default file contents, as well
179 as named data streams if supported by the target volume.
180 .IP \[bu]
181 Reparse points, including symbolic links, junction points, and other reparse
182 points, if supported by the target volume.  (Note: see \fB--rpfix\fR and
183 \fB--norpfix\fR for documentation on exactly how absolute symbolic links and
184 junctions are extracted.)  However, as per the default security settings of
185 Windows, it is impossible to create a symbolic link or junction point without
186 Administrator privileges; therefore, you must run \fB@IMAGEX_PROGNAME@\fR as the
187 Administrator if you wish to fully restore an image containing symbolic links
188 and/or junction points.  (Otherwise, merely a warning will be issued when a
189 symbolic link or junction point cannot be extracted due to insufficient
190 privileges.)
191 .IP \[bu]
192 File and directory creation, access, and modification timestamps, to the highest
193 resolution supported by the target volume.
194 .IP \[bu]
195 Security descriptors, if supported by the filesystem and \fB--no-acls\fR is not
196 specified.  Furthermore, unless \fB--strict-acls\fR is specified, the security
197 descriptors for individual files or directories may be omitted or only partially
198 set if the user does not have permission to set them, which can be a problem if
199 \fB@IMAGEX_PROGNAME@\fR is run as a non-Administrator.
200 .IP \[bu]
201 File attributes, including hidden, sparse, compressed, encrypted, etc, when
202 supported by the filesystem.
203 .IP \[bu]
204 DOS names (8.3) names of files; however, the failure to set them is not
205 considered an error condition.
206 .IP \[bu]
207 Hard links, if supported by the filesystem.
208 .PP
209 Additional notes about extracting files on Windows:
210 .IP \[bu] 4
211 \fB@IMAGEX_PROGNAME@\fR will always issue a warning when it is unable to extract
212 the exact metadata and data of the WIM image, for example due to features
213 mentioned above not being supported by the target filesystem.
214 .IP \[bu]
215 Since encrypted files (with FILE_ATTRIBUTE_ENCRYPTED) are not stored in
216 plaintext in the WIM image, \fB@IMAGEX_PROGNAME@\fR cannot restore encrypted
217 files to filesystems not supporting encryption.  (The current behavior is to
218 just extract the encrypted data anyway.)  Furthermore, even if encrypted files
219 are restored to a filesystem that supports encryption, they will only be
220 decryptable if the decryption key is available.
221 .IP \[bu]
222 Files with names that cannot be represented on Windows will not
223 be extracted by default; see \fB--include-invalid-names\fR.
224 .IP \[bu]
225 Files with full paths over 260 characters (MAX_PATH) are extracted by using the
226 \\\\?\\-prefixed path hack.  But beware that such files will be inaccessible to
227 most Windows software and may not be able to be deleted easily.
228 .SH SPLIT WIMS
229 You may use \fB@IMAGEX_PROGNAME@ apply\fR to apply images from a split WIM.  The
230 \fIWIMFILE\fR argument is used to specify the first part of the split WIM, and
231 the \fB--refs\fR="\fIGLOB\fR" option is used to provide a shell-style file glob
232 that specifies the additional parts of the split WIM.  \fIGLOB\fR is expected to
233 be a single string on the command line, so \fIGLOB\fR must be quoted so that it
234 is protected against shell expansion.  \fIGLOB\fR must expand to all parts of
235 the split WIM, except optionally the first part which may either omitted or
236 included in the glob (but the first part MUST be specified as \fIWIMFILE\fR as
237 well).
238 .PP
239 Here's an example.  The names for the split WIMs usually go something like:
240 .RS
241 .PP
242 .nf
243 mywim.swm
244 mywim2.swm
245 mywim3.swm
246 mywim4.swm
247 mywim5.swm
248 .RE
249 .fi
250 .PP
251 To apply the first image of this split WIM to the directory "dir", run:
252 .PP
253 .RS
254 @IMAGEX_PROGNAME@ apply mywim.swm 1 dir --ref="mywim*.swm"
255 .RE
256 .PP
257 As a special case, if you are applying an image from standard input from a split
258 WIM that is also pipable (as described in \fBPIPABLE WIMS\fR), the \fB--ref\fR
259 option is unneeded; instead you must ensure that all the split WIM parts are
260 concatenated together on standard input.  They can be provided in any order,
261 with the exception of the first part, which must be first.
262 .SH PIPABLE WIMS
263 As of wimlib 1.5.0, \fB@IMAGEX_PROGNAME@ apply\fR supports applying a WIM from a
264 nonseekable file, such as a pipe, provided that the WIM was captured with
265 \fB--pipable\fR (see \fB@IMAGEX_PROGNAME@ capture\fR(1)).  To use standard input
266 as the WIM, specify "-" as \fIWIMFILE\fR.  A useful use of this ability is to
267 apply an image from a WIM while streaming it from a webserver; for example, to
268 apply the first image from a WIM file to an NTFS volume on /dev/sda1:
269 .PP
270 .RS
271 wget -O - http://myserver/mywim.wim | wimapply - 1 /dev/sda1
272 .RE
273 .PP
274 (The above also used the \fBwimapply\fR abbreviation for \fB@IMAGEX_PROGNAME@
275 apply\fR.) Note: WIM files are \fInot\fR pipable by default; you have to
276 explicitly capture them with \fB--pipable\fR, and they are \fInot\fR compatible
277 with Microsoft's software.  See \fB@IMAGEX_PROGNAME@ capture\fR(1) for more
278 information.
279 .PP
280 It is possible to apply an image from a pipable WIM split into multiple parts;
281 see \fBSPLIT WIMS\fR.
282 .SH OPTIONS
283 .TP 6
284 \fB--check\fR
285 When reading \fIWIMFILE\fR, verify its integrity if the integrity table is
286 present.
287 .TP
288 \fB--ref\fR="\fIGLOB\fR"
289 File glob of additional split WIM parts that are part of the split WIM being
290 applied.  See \fBSPLIT_WIMS\fR.
291 .TP
292 \fB--rpfix\fR, \fB--norpfix\fR
293 Set whether to fix targets of absolute symbolic links (reparse points in Windows
294 terminology) or not.  When enabled (\fB--rpfix\fR), extracted absolute symbolic
295 links that are marked in the WIM image as being fixed are assumed to have
296 absolute targets relative to the image root, and therefore have the actual root
297 of extraction prepended to their targets.  The intention is that you can apply
298 an image containing absolute symbolic links and still have them be valid after
299 it has been applied to any location.
300 .IP ""
301 The default behavior is \fB--rpfix\fR if any images in \fIWIMFILE\fR have been
302 captured with reparse-point fixups done.  Otherwise, it is \fB--norpfix\fR.
303 .IP ""
304 Reparse point fixups are never done in the NTFS volume extraction mode on
305 UNIX-like systems.
306 .IP ""
307 \fB--verbose\fR
308 Print the path to of each file or directory within the WIM image as it is
309 extracted.
310 .TP
311 \fB--hardlink\fR
312 When extracting a file from the WIM that is identical to a file that has already
313 extracted, create a hard link rather than creating a separate file.  This option
314 causes all identical files to be hard-linked, overriding the hard link groups
315 that are specified in the WIM image(s).  In the case of extracting all images
316 from the WIM, files may be hard-linked even if they are in different WIM images.
317 .IP ""
318 However, hard-linked extraction mode does have some additional quirks.  Named
319 data streams will not be extracted, and files can be hard linked even if their
320 metadata is not fully consistent.
321 .TP
322 \fB--symlink\fR
323 This option is similar to \fB--hardlink\fR, except symbolic links are created
324 instead.
325 .TP
326 \fB--unix-data\fR
327 (UNIX-like systems only)  By default, in the directory extraction mode on UNIX,
328 \fB@IMAGEX_PROGNAME@ apply\fR will ignore both Windows-style security
329 descriptors and UNIX-specific file owners, groups, and modes set when using
330 \fB@IMAGEX_PROGNAME@ capture\fR with the \fB--unix-data\fR flag.  By passing
331 \fB--unix-data\fR to \fB@IMAGEX_PROGNAME@ apply\fR instead, this causes this
332 UNIX-specific data to be restored when available.  However, by default, if
333 \fB@IMAGEX_PROGNAME@\fR does not have permission to set the UNIX owner, group or
334 file mode on an extracted file, a warning will be printed and it will not be
335 considered an error condition; use \fB--strict-acls\fR to get stricter behavior.
336 .TP
337 \fB--no-acls\fR
338 Do not restore security descriptors on extracted files and directories.
339 .TP
340 \fB--strict-acls\fR
341 Fail immediately if the full security descriptor of any file or directory cannot
342 be set exactly as specified in the WIM file.  On Windows, the default behavior
343 without this option is to fall back to setting a security descriptor with the
344 SACL omitted, then only the default inherited security descriptor, if
345 \fB@IMAGEX_PROGNAME@\fR does not have permission to set the desired one.  Also,
346 on UNIX-like systems, this flag can also be combined with \fB--unix-data\fR to
347 cause \fB@IMAGEX_PROGNAME@\fR to fail immediately if the UNIX owner, group, or
348 mode on an extracted file cannot be set for any reason.
349 .TP
350 \fB--include-invalid-names\fR
351 Extract files and directories with invalid names by replacing characters and
352 appending a suffix rather than ignoring them.  The meaning of this is
353 platform-dependent.
354 .IP "" 6
355 On POSIX-compliant systems, filenames are case-sensitive and may contain any
356 byte except '\\0' and \'/', so on a POSIX-compliant system this option will only
357 have an effect in the unlikely case that the WIM image for some reason has a
358 filename containing one of these characters.
359 .IP "" 6
360 On Windows, filenames are case-insensitive, cannot include the characters '/',
361 \'\\0', '\\', ':', '*', '?', '"', '<', '>', or '|', and cannot end with a space
362 or period.  Ordinarily, files in WIM images should meet these conditions as
363 well. However, it is not guaranteed, and in particular a WIM image captured with
364 \fB@IMAGEX_PROGNAME@\fR on a POSIX-compliant system could contain such files.  By
365 default, invalid names will be ignored, and if there are multiple names
366 differing only in case, one will be chosen to extract arbitrarily; however, with
367 \fB--include-invalid-names\fR, all names will be sanitized and extracted in some
368 form.
369 .SH NOTES
370 \fB@IMAGEX_PROGNAME@ apply\fR calculates the SHA1 message digest of every file
371 stream it extracts and verifies that it is the same as the SHA1 message digest
372 provided in the WIM file.  It is an error if the message digests don't match.
373 It's also considered to be an error if any WIM resources that need to be
374 extracted cannot be found in the stream lookup table.  So you can be fairly
375 certain that the file streams are extracted correctly, even though
376 \fB@IMAGEX_PROGNAME@ apply\fR don't have a \fB/verify\fR option like Microsoft's
377 ImageX does.  Note that this is separate from the integrity table of the WIM,
378 which provides SHA1 message digests over raw chunks of the entire WIM file and
379 is checked separately if the \fB--check\fR option is specified.
380 .SH EXAMPLES
381 Extract the first image from the Windows PE image on the Windows Vista/7/8
382 installation media to the directory "boot":
383 .RS
384 .PP
385 @IMAGEX_PROGNAME@ apply /mnt/windows/sources/boot.wim 1 boot
386 .RE
387 .PP
388 Same as above, but using the \fBwimapply\fR abbreviation:
389 .RS
390 .PP
391 wimapply /media/windows/sources/boot.wim 1 boot
392 .RE
393 .PP
394 On Windows, apply an image of an entire volume, for example from "install.wim"
395 which can be found on the Windows Vista/7/8 installation media:
396 .RS
397 .PP
398 @IMAGEX_PROGNAME@ apply install.wim 1 E:\\
399 .RE
400 .PP
401 Same as above, but running on a UNIX-like system where the corresponding
402 partition is /dev/sda2:
403 .RS
404 .PP
405 @IMAGEX_PROGNAME@ apply install.wim 1 /dev/sda2
406 .RE
407 .PP
408 Note that before running either of the above commands, an NTFS filesystem may
409 need to be created on the partition, for example with format.exe on Windows or
410 \fBmkntfs\fR(8) (part of NTFS-3g) on UNIX-like systems.  For example, you might
411 run:
412 .RS
413 .PP
414 mkntfs /dev/sda2 && wimapply install.wim 1 /dev/sda2
415 .RE
416 .PP
417 (Of course don't do that if you don't want to destroy all existing data on the
418 partition!)
419 .PP
420 An example of applying a pipable WIM from a pipe can be found in \fBPIPABLE
421 WIMS\fR, and an example of applying a split WIM can be found in \fBSPLIT
422 WIMS\fR.
423 .PP
424 And finally, just for fun, a silly way to recursively copy a directory tree
425 \fIsrc\fR to \fIdst\fR (but subject to the documented limitations, e.g.
426 platform and filesystem-dependent, of the capture and apply functionality of
427 \fB@IMAGEX_PROGNAME@\fR):
428 .RS
429 .PP
430 @IMAGEX_PROGNAME@ capture src - | @IMAGEX_PROGNAME@ apply - 1 dst
431 .RE
432 .PP
433 .SH SEE ALSO
434 .BR @IMAGEX_PROGNAME@ (1)
435 .BR @IMAGEX_PROGNAME@-capture (1)
436 .BR @IMAGEX_PROGNAME@-extract (1)
437 .BR @IMAGEX_PROGNAME@-info (1)