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