wimlib-imagex-append - Online sa Cloud

PROGRAMA:

NAME

wimlib-imagex-capture, wimlib-imagex-append - Lumikha o magdagdag ng WIM na imahe

SINOPSIS

wimlib-imagex pagbihag SOURCE WIMFILE [IMAGE_NAME [DESKRIPSYON SA LARAWAN]] [OPTION...]
wimlib-imagex apendend SOURCE WIMFILE [IMAGE_NAME [DESKRIPSYON SA LARAWAN]] [OPTION...]

DESCRIPTION

Ang wimlib-imagex pagbihag at wimlib-imagex apendend ang mga utos ay lumikha ng isang Windows Imaging (WIM)
larawan mula sa puno ng direktoryo. Ang wimlib-imagex pagbihag Ang command ay lumilikha ng bagong WIM file
naglalaman ng nakunan na imahe, habang ang wimlib-imagex apendend idinaragdag ng utos ang nahuli
larawan sa isang umiiral nang WIM file. Ang mga utos na ito ay magagamit din bilang simple wimcapture at
wimappend kung naka-install ang naaangkop na mga hard link o batch file.

Impormasyon sa background: Ang isang imahe ng WIM ay isang independiyenteng puno ng direktoryo sa isang WIM file. Isang WIM
Ang file ay maaaring maglaman ng anumang bilang ng mga hiwalay na larawan. Ang mga WIM file ay nag-iisang instance sa
tungkol sa data ng file, kaya ang isang file ay nakaimbak lamang ng isang beses sa buong WIM, anuman ang
kung gaano karaming mga larawan ang lalabas sa file.

SOURCE tumutukoy sa lokasyon ng mga file kung saan likhain ang bagong imahe ng WIM. Kung SOURCE is
isang direktoryo, ang imahe ng WIM ay nakuha mula sa direktoryo na iyon (tingnan DIRECTORY KARAPATAN (UNIX)
or DIRECTORY KARAPATAN (WINDOWS)). Bilang kahalili, kung ang --source-list Ang opsyon ay
tinukoy, SOURCE ay binibigyang-kahulugan bilang isang file na nagbibigay mismo ng isang listahan ng mga file at
mga direktoryo na isasama sa bagong imahe ng WIM. Bilang kahalili, tanging sa UNIX-like
mga sistema, kung SOURCE ay isang regular na file o block device, ito ay binibigyang kahulugan bilang isang volume ng NTFS
kung saan kukunan ang isang imahe ng WIM gamit ang libntfs-3g (tingnan ang NTFS VOLUME KARAPATAN
(UNIX)).

IMAGE_NAME at DESKRIPSYON SA LARAWAN tukuyin ang pangalan at paglalarawan upang ibigay ang bagong WIM
larawan. Kung IMAGE_NAME ay hindi tinukoy, nagde-default ito sa base name (hindi kasama ang path sa
direktoryo ng magulang) ng SOURCE, ngunit kung mayroon nang pangalang ito sa WIMFILE, isang natatanging suffix
Ay dinagdag. kung hindi, IMAGE_NAME dapat ay alinman sa isang pangalan na hindi pa umiiral bilang isang
imahe sa WIMFILE, o ang walang laman na string upang lumikha ng isang imahe na walang pangalan. Kung
DESKRIPSYON SA LARAWAN ay hindi tinukoy, walang paglalarawan na ibinigay sa bagong larawan.

Bilang isang espesyal na kaso, kung WIMFILE ay ang --pipable ang opsyon ay ipinapalagay at ang WIM file ay
nakasulat sa karaniwang output sa isang espesyal na piable na format. Tingnan ang dokumentasyon para sa
--pipable para sa karagdagang detalye.

DIRECTORY KARAPATAN (UNIX)

Ang seksyong ito ay nagdodokumento kung paano wimlib-imagex kumukuha ng mga file mula sa isang puno ng direktoryo sa tulad ng UNIX
mga sistema. Tingnan mo DIRECTORY KARAPATAN (WINDOWS) para sa kaukulang dokumentasyon para sa Windows.

Sa mga sistemang tulad ng UNIX, kapag SOURCE tumutukoy sa isang direktoryo o isang simbolikong link sa isang direktoryo,
ang imahe ng WIM ay kukunan mula sa puno ng direktoryo na na-root sa direktoryong ito. Ito
ang direktoryo ay maaaring nasa anumang uri ng filesystem, at ang mga mountpoint ay sinusunod nang recursively. Sa
sa mode na ito, ang wimlib ay mag-iimbak ng mga sumusunod na uri ng impormasyon:

· Mga direktoryo at regular na file, at ang mga nilalaman ng mga regular na file

· Matigas na mga link

· Mga simbolikong link (na-translate nang walang pagkawala sa mga reparse point ng Windows)

· Mga huling oras ng pagbabago (mtime) at huling oras ng pag-access (atime) na may 100 nanosecond
butil

· Kasama --unix-data: Mga may-ari, grupo, at mode ng UNIX

· Kasama --unix-data: mga node ng device, mga FIFO, at mga socket ng domain ng UNIX

Walang suporta para sa pag-iimbak ng mga pinahabang katangian (hal. SELinux security label at
POSIX ACLs). Tandaan din na hindi nakaimbak ang mga huling oras ng pagbabago ng status (ctime).

Pedantic note: Pinipigilan ng isang limitasyon ng format ng WIM ang hindi pangkaraniwang kaso kung saan ang isang solong
symbolic link file mismo ay may maraming mga pangalan (hard links); sa hindi malamang kaso na ito, bawat isa
Ang simbolikong link ay naka-imbak bilang isang independiyenteng file.

NTFS VOLUME KARAPATAN (UNIX)

Ang seksyong ito ay nagdodokumento kung paano wimlib-imagex direktang kumukuha ng mga file mula sa isang NTFS volume image
sa mga sistemang tulad ng UNIX.

Sa mga sistemang tulad ng UNIX, ang isang espesyal na mode ng pagkuha ng imahe ay ipinasok kapag SOURCE ay isang regular
file o i-block ang device. Sa mode na ito, SOURCE ay ipinapalagay na isang NTFS volume o volume
larawan, at wimlib-imagex ay kukuha ng imahe ng WIM na naglalaman ng buong nilalaman ng NTFS
volume, kabilang ang data na tukoy sa NTFS. Ginagawa ito gamit ang libntfs-3g.

Tandaan na ang NTFS volume capture mode ay hindi ipinasok kung SOURCE ay isang direktoryo, kahit na ang isang
Naka-mount ang NTFS filesystem SOURCE gamit ang ntfs-3g. Dapat mong tukuyin ang dami ng NTFS
mismo (at dapat itong i-unmount, at dapat may pahintulot kang magbasa mula rito).

Sinusubukan ng NTFS volume capture mode na kumuha ng mas maraming data at metadata hangga't maaari,
kabilang ang:

· Lahat ng data stream ng lahat ng hindi naka-encrypt na file, kasama na rin ang hindi pinangalanang stream ng data
bilang lahat ng pinangalanang data stream.

· Mga reparse point, kabilang ang mga simbolikong link, junction point, at iba pang reparse point.

· Paglikha ng file at direktoryo, pag-access, at pagbabago ng mga timestamp, gamit ang native
NTFS resolution ng 100 nanoseconds.

· Mga tagapaglarawan ng seguridad ng Windows, kabilang ang lahat ng bahagi (may-ari, grupo, DACL, at SACL).

· Mga flag ng katangian ng DOS/Windows file.

· Lahat ng mga pangalan ng lahat ng mga file, kabilang ang mga pangalan sa Win32 namespace, DOS namespace,
Win32+DOS namespace, at POSIX namespace. Kabilang dito ang mga hard link.

Gayunpaman, ang mga pangunahing limitasyon ng NTFS volume capture mode na ito ay:

· Ang mga naka-encrypt na file ay hindi kasama bilang default. Bagama't nababasa ng libntfs-3g ang kanilang data,
kailangan nilang itago sa WIM file sa isang espesyal na format na hindi pa ginagawa ng wimlib
suporta (maliban sa Windows, kung saan maaaring ituring ng wimlib ang data bilang opaque at ibigay ito
sa naaangkop na function ng API).

· Ang kalat-kalat na katangian sa mga kalat-kalat na file ay isi-save, ngunit ang data na nakaimbak ay ang
buong data ng file sa halip na ang "kalat-kalat" na data. (Ang data ay, gayunpaman, paksa
sa compression ng WIM format.)

DIRECTORY KARAPATAN (WINDOWS)

Sa Windows, wimlib-imagex pagbihag at wimlib-imagex apendend katutubong sumusuporta sa Windows-
tiyak at NTFS-specific na data. Kaya't sila ay kumikilos nang katulad sa nararapat
mga utos ng ImageX o DISM ng Microsoft. Para sa pinakamahusay na mga resulta, kinukuha ang direktoryo
dapat ay nasa dami ng NTFS at wimlib-imagex dapat patakbuhin na may mga pribilehiyo ng Administrator;
gayunpaman, ang mga non-NTFS filesystem at tumatakbo nang walang mga pribilehiyo ng Administrator ay mayroon din
suportado.

Sa Windows, wimlib-imagex pagbihag at wimlib-imagex apendend subukang mag-archive ng maraming data at
metadata hangga't maaari, kabilang ang:

· Lahat ng data stream ng lahat ng mga file.

· Mga reparse point, kabilang ang mga simbolikong link, junction point, at iba pang reparse point,
kung sinusuportahan ng source filesystem. (Tandaan: tingnan --rpfix at --norpfix para
dokumentasyon sa eksakto kung paano kinukuha ang ganap na simbolikong mga link at junction.)

· Paglikha ng file at direktoryo, pag-access, at mga timestamp ng pagbabago. Ang mga ito ay nakaimbak
na may katutubong timestamp na resolution ng Windows NT na 100 nanosecond.

· Mga deskriptor ng seguridad, kung sinusuportahan ng source filesystem at --no-acls Hindi
tinukoy. Gayunpaman, mag-ingat na maliban kung --mahigpit-acls ay tinukoy, ang seguridad
Ang mga deskriptor para sa mga indibidwal na file o direktoryo ay maaaring tanggalin o bahagyang lamang
nakunan kung walang pahintulot ang user na basahin ang mga ito, na maaaring maging problema kung
wimlib-imagex ay pinapatakbo bilang isang hindi Administrator.

· Mga katangian ng file, kabilang ang nakatago, kalat-kalat, naka-compress, naka-encrypt, atbp. Naka-encrypt
ang mga file ay maiimbak sa naka-encrypt na anyo sa halip na sa simpleng teksto. Malinaw
Ang mga naka-compress na file ay mababasa bilang hindi naka-compress at nakaimbak na napapailalim sa sariling WIM
compression. Walang espesyal na paghawak para sa pag-iimbak ng mga kalat-kalat na file, ngunit sila ay
malamang na mag-compress sa maliit na sukat.

· Mga pangalan ng DOS (8.3) mga pangalan ng mga file; gayunpaman, ang kabiguang basahin ang mga ito ay hindi itinuturing na isang
kondisyon ng error.

· Mga hard link, kung sinusuportahan ng source filesystem.

Walang suporta para sa pag-iimbak ng mga pinahabang katangian at object ID ng NTFS.

Ang proseso ng pagkuha ay nababaligtad, mula noong wimlib-imagex mag-aplay (sa Windows) na mga extract
ang nakunan na imahe ng WIM, kukunin nito ang lahat ng impormasyon sa itaas, hindi bababa sa
lawak na sinusuportahan ng patutunguhang filesystem.

Pedantic note: dahil ang Windows ay hindi ganap na compatible sa sarili nitong filesystem (NTFS), naka-on
Hindi mai-archive ng Windows wimlib ang ilang partikular na file na maaaring umiiral sa isang wastong NTFS filesystem ngunit
ay hindi naa-access sa Windows API, halimbawa dalawang file na may pagkakaiba lamang sa mga pangalan
kaso sa parehong direktoryo, o isang file na ang pangalan ay naglalaman ng ilang partikular na character na isinasaalang-alang
hindi wasto ng Windows. Kung magkakaroon ka ng mga problema sa pag-archive ng mga naturang file isaalang-alang ang paggamit ng NTFS
VOLUME KARAPATAN (UNIX) mode mula sa Linux.

Opsyon

--boot
Tinutukoy na ang bagong imahe ay gagawing bootable na imahe ng WIM archive.

--suriin
para wimlib-imagex apendend, bago isagawa ang pagpapatakbo ng append, suriin ang
integridad ng WIMFILE kung mayroong talahanayan ng integridad. Higit pa rito, isama ang isang
talahanayan ng integridad sa bagong WIM file (wimlib-imagex pagbihag) o ang binagong WIM file
(wimlib-imagex apendend). Kung ang opsyong ito ay hindi tinukoy, walang integridad na talahanayan ay
kasama sa isang WIM file na ginawa gamit ang wimlib-imagex pagbihag, habang na-update ang isang WIM file
sa wimlib-imagex apendend ay isusulat na may talahanayan ng integridad kung at kung isa lamang
ay naroroon noon.

--compress=TYPE[:ANTAS]
Tinutukoy ang format ng compression para sa bagong WIM file. TYPE maaaring "wala", "XPRESS"
(alias: "mabilis"), "LZX" (alias: "maximum"), o "LZMS" (alias: "recovery"). TYPE is
tumugma sa case-insensitive. Ang default ay "LZX".

Maaari mo ring tukuyin ang isang integer compression ANTAS. Ang antas ng compression
tumutukoy kung gaano kahirap ang compression algorithm para sa tinukoy na compression TYPE habilin
gumana upang i-compress ang data. Ang mga halaga ay pinaliit upang ang 20 ay mabilis na pag-compress,
50 ay medium compression, at 100 ay high compression. Gayunpaman, maaari kang pumili ng anuman
halaga, at hindi lamang ang mga partikular na halagang ito. Ang default ay 50.

Ang pagpipiliang ito ay nakakaapekto lamang sa uri ng compression na ginagamit sa hindi solidong mga mapagkukunan ng WIM. Kung
ikaw ay lumilikha ng isang solidong WIM (gamit ang --matibay opsyon), pagkatapos ay malamang na gusto mo
--solid-compress sa halip.

Mag-ingat kung pipiliin mo ang LZMS compression. Hindi ito tugma sa wimlib dati
v1.6.0, WIMGAPI bago ang Windows 8, DISM bago ang Windows 8.1, at 7-Zip bago ang v15.12.

Tandaan din na ang pagpili ng LZMS compression ay hindi awtomatikong nagpapahiwatig ng solid-mode
compression, tulad ng ginagawa nito sa DISM. Gamitin --matibay kung gusto mong lumikha ng solidong WIM,
o "ESD file".

--laki ng tipak=SIZE
Itakda ang laki ng compression chunk sa SIZE byte. Isang mas malaking sukat ng compression chunk
nagreresulta sa isang mas mahusay na ratio ng compression. Sinusuportahan ng wimlib ang iba't ibang laki ng tipak
depende sa uri ng compression:

· XPRESS: 4K, 8K, 16K, 32K, 64K

· LZX: 32K, 64K, 128K, 256K, 512K, 1M, 2M

· LZMS: 32K, 64K, 128K, 256K, 512K, 1M, 2M, 4M, 8M, 16M, 32M, 64M, 128M, 256M, 512M,
1G

Maaari mong ibigay ang buong numero (hal. 32768), o maaari mong gamitin ang isa sa K, M, o G
mga panlapi. Tinatanggap din ang KiB, MiB, at GiB.

Ang pagpipiliang ito ay nakakaapekto lamang sa laki ng tipak na ginagamit sa hindi solidong mga mapagkukunan ng WIM. Kung ikaw ay
paglikha ng matatag na WIM (gamit ang --matibay opsyon), pagkatapos ay malamang na gusto mo --matibay-
laki ng tipak sa halip.

Gamitin ang opsyong ito nang may pag-iingat kung ang pagiging tugma sa pagpapatupad ng Microsoft ay
ninanais, dahil ang kanilang pagpapatupad ay may limitadong suporta para sa mga hindi default na laki ng tipak.

--matibay
Gumawa ng "solid" na WIM file na nagpi-compress ng mga file nang magkasama sa halip na independyente.
Nagreresulta ito sa isang makabuluhang mas mahusay na ratio ng compression, ngunit ito ay dumating sa halaga
ng iba't ibang tradeoff, kabilang ang: mabagal na compression na may napakataas na paggamit ng memory; mabagal
random na pag-access sa nagresultang WIM file; at nabawasan ang pagiging tugma.

Compatibility-wise, ang unang bersyon ng WIMGAPI ng Microsoft na sumusuporta sa solidong WIM
Ang mga file ay inilabas gamit ang Windows 8, at ang unang bersyon ng DISM na gumawa nito ay
inilabas gamit ang Windows 8.1.

Kung gusto mong gumawa ng "ESD file", pagkatapos ay gamitin ang opsyong ito. Isang (hindi naka-encrypt) "ESD
file" ay isang solidong WIM file.

Bilang default, ang opsyong ito ay may katumbas na epekto sa opsyon ng DISM
/compress:recovery. Ang mga opsyon para sa wimlib-imagex ay iba dahil sinusubukan nila
hindi upang pagsamahin ang uri ng compression (hal. LZX o LZMS) sa solid-mode compression,
dahil ito ay dalawang magkaibang bagay.

--solid-chunk-size=SIZE
katulad --laki ng tipak, ngunit itakda ang laki ng tipak na ginamit sa mga solidong mapagkukunan. Ang default,
sa pag-aakalang LZMS compression, ay 64MiB (67108864); nangangailangan ito ng humigit-kumulang 640MiB ng memorya
bawat thread. Ang pagpipiliang ito ay may epekto lamang kapag --matibay ay tinukoy din. Tandaan:
Ang pagpapatupad ng Microsoft ay hindi tugma sa LZMS chunk sizes na mas malaki kaysa sa
64MiB.

--solid-compress=TYPE[:ANTAS]
katulad --compress, ngunit itakda ang uri ng compression na ginamit sa mga solidong mapagkukunan. Ang default
ay LZMS compression. Ang pagpipiliang ito ay may epekto lamang kapag --matibay ay tinukoy din.

--mga thread=NUM_THREADS
Bilang ng mga thread na gagamitin para sa pag-compress ng data. Default: autodetect (bilang ng
magagamit na mga CPU).

--muling itayo
para wimlib-imagex apendend: muling itayo ang buong WIM sa halip na idagdag ang bagong data
hanggang sa dulo nito. Ang muling pagtatayo ng WIM ay mas mabagal, ngunit makakatipid ng kaunting espasyo
na kung hindi man ay maiiwan bilang isang butas sa WIM. Tingnan din wimlib-imagex
optimizeNa (1).

--mga watawat=EDITIONID
Tumukoy ng string na gagamitin sa elemento ng XML data para sa bagong larawan.

--image-property NAME=VALUE
Tumukoy ng arbitrary na per-image na property na itatakda sa XML na dokumento ng WIM file.
VALUE ay ang string na itatakda bilang value ng property. NAME ay ang pangalan ng larawan
property, halimbawa "NAME", "DESCRIPTION", o "TOTALBYTES". Maaaring naglalaman ang pangalan
forward slashes upang ipahiwatig ang isang nested XML na elemento; Halimbawa,
Isinasaad ng "WINDOWS/VERSION/BUILD" ang elementong BUILD na naka-nest sa loob ng VERSION
elementong nakapugad sa loob ng elemento ng WINDOWS. Maaaring gamitin ang isang naka-bracket na numero
ipahiwatig ang isa sa ilang magkakatulad na pangalan na elemento; Halimbawa,
Isinasaad ng "WINDOWS/LANGUAGES/LANGUAGE[2]" ang pangalawang elementong "LANGUAGE" na naka-nest
sa loob ng elementong "WINDOWS/LANGUAGES". Kapag nagdaragdag ng listahan ng mga elemento sa ganitong paraan,
dapat na tukuyin ang mga ito sa sequential order. Tandaan na ang mga pangalan ng elemento ay case-
sensitibo. Maaaring tukuyin ang opsyong ito nang maraming beses.

--dereference
(UNIX-like system lang) Sundin ang mga simbolikong link at i-archive ang mga file na kanilang itinuturo,
sa halip na i-archive ang mga link mismo.

--config=FILE
Tumutukoy ng configuration file (UTF-8 o UTF-16LE na naka-encode; gumagana din ang plain ASCII)
para sa pagkuha ng bagong larawan. Ang configuration file ay tumutukoy sa mga file na dapat
lalo na ginagamot sa panahon ng pagkuha ng larawan.

Ang format ng configuration file ay INI-style; ibig sabihin, ito ay nakaayos sa
naka-bracket na mga seksyon. Sa kasalukuyan, kinikilala ang mga sumusunod na seksyon:

· [ExclusionList] --- naglalaman ng listahan ng mga path glob na ibukod mula sa pagkuha. Kung
ang isang direktoryo ay tumugma, ang direktoryo at ang mga nilalaman nito ay hindi kasama.

· [ExclusionException] --- naglalaman ng listahan ng mga path glob na isasama sa
makuha, kahit na ang file o direktoryo ay tumugma din sa isang glob sa [ExclusionList].

· [PrepopulateList] --- hindi ito makakaapekto sa pagkuha, ngunit kung ang imahe ay inilapat
mamaya kasama --wimboot, ito ay mga glob ng mga file na dapat i-extract nang normal,
hindi bilang WIMBoot na "pointer files". Kung ang isang direktoryo ay tumugma, lahat ng mga file at
ang mga subdirectory ay tinutugma din nang recursively.

Ang mga path glob ay maaaring maglaman ng '*' at '?' meta-character. Mga kaugnay na glob (hal
*.mp3) na tumutugma sa isang filename sa anumang direktoryo. Mga ganap na glob (hal. /dir/file),
ay itinuturing bilang mga landas na nagsisimula sa pangunahing direktoryo na kinukuha, o ang ugat ng
ang NTFS volume para sa NTFS volume capture mode. Huwag gumamit ng mga drive letter sa
mga landas; hindi sila papansinin. Ang mga separator ng landas ay maaaring alinman sa mga forward slash o
paatras na mga laslas.

Mga linyang nagsisimula sa '#' o ';' ang mga character ay tinatrato bilang mga komento at binabalewala.
Ang mga glob na may whitespace sa mga ito ay hindi kailangang banggitin; gayunpaman, kung sila ay, parehong doble
at tinatanggap ang mga single quotes.

Kung ang opsyong ito ay hindi tinukoy ang sumusunod na default na configuration file ay ginagamit:

[ExclusionList]
\$ntfs.log
\hiberfil.sys
\pagefile.sys
\swapfile.sys
\System Volume Information
\RECYCLER
\Windows\CSC

Gayunpaman, nalalapat ang espesyal na pag-uugali kung --wimboot ay tinukoy din. Bilang default, may
--wimboot tinukoy, ang file na Windows/System32/WimBootCompress.ini sa direktoryo
ang na-capture ay gagamitin bilang configuration file. Gayunpaman, maaari itong maging
na-override gamit --config; at nagiging sanhi din ito ng tinukoy na configuration file sa
mai-save sa imahe ng WIM bilang Windows/System32/WimBootCompress.ini, na pinapalitan ang anumang
na maaaring naroroon sa filesystem.

--unix-data
(Mga system na parang UNIX lang) I-store ang may-ari ng UNIX, grupo, mode, at device ID (pangunahin at
menor de edad) ng bawat nakuhang file. Bilang ng wimlib v1.7.0, maaari kang mag-backup at
ibalik hindi lamang ang karaniwang impormasyon ng pahintulot ng file ng UNIX, kundi pati na rin ang karakter
device node, block device node, pinangalanang pipe (FIFOs), at UNIX domain sockets.

Ang wimlib ay nag-iimbak ng data ng UNIX sa pamamagitan ng pagdaragdag ng isang espesyal na naka-tag na metadata item sa bawat direktoryo
entry ng bawat file na naglalaman ng impormasyong ito. Ang karagdagang impormasyon na ito ay
hindi pinansin ng pagpapatupad ng Microsoft. Tandaan: UNIX data na inimbak ng wimlib bago
Ang v1.7.0 ay gumamit ng ibang format na hindi na sinusuportahan. Kung mayroon kang lumang WIM
mga file na may data ng UNIX, ilapat ang mga ito gamit ang v1.6.2 at kunin muli ang mga ito gamit ang v1.7.0 o
mamaya.

--no-acls
Huwag kumuha ng mga deskriptor ng seguridad ng mga file.

--mahigpit-acls
Mabigo kaagad kung hindi mababasa ang buong deskriptor ng seguridad ng anumang file. Naka-on
Windows, ang default na gawi kung wala ang opsyong ito ay subukan munang alisin ang SACL
mula sa security descriptor, pagkatapos ay subukang ganap na alisin ang security descriptor.
Ang layunin nito ay kumuha ng mas maraming data hangga't maaari nang hindi palaging nangangailangan
Mga pribilehiyo ng administrator. Gayunpaman, kung nais mo na ang lahat ng mga deskriptor ng seguridad ay
nakunan nang eksakto, maaaring naisin mong ibigay ang opsyong ito, kahit na ang Administrator
dapat may pahintulot na basahin ang lahat.

--rpfix, --norpfix
Itakda kung aayusin ang mga target ng ganap na simbolikong mga link (reparse point sa Windows
terminolohiya) o hindi. Kapag pinagana (--rpfix), ganap na simbolikong mga link sa puntong iyon
sa loob ng puno ng direktoryo na kinukunan ay iaakma upang maging ganap na nauugnay sa
ang ugat ng puno ng direktoryo na nakunan. Kapag may kapansanan (--norpfix), ganap
Ang mga simbolikong link ay kukunan nang eksakto kung ano ang dati.

Ang default na gawi para sa wimlib-imagex pagbihag ay katumbas ng --rpfix. ang
default na pag-uugali para sa wimlib-imagex apendend ay --rpfix kung reparse point fixups
ay dati nang ginawa sa WIMFILE, Kung hindi man --norpfix.

Sa kaso ng isang multi-source capture, (--source-list tinukoy), pagpasa --norpfix
Inirerekomenda. Kung hindi, idi-disable ang mga reparse point fixup sa lahat ng pagkuha
pinagmumulan na nakalaan para sa mga lokasyong hindi nag-ugat sa larawan ng WIM, habang kumukuha ng mga mapagkukunan
na nakalaan para sa ugat ng WIM ay makakakuha ng default na gawi mula sa nakaraang talata.

--source-list
wimlib-imagex pagbihag at wimlib-imagex apendend suporta sa paglikha ng isang imahe ng WIM mula sa
maramihang hiwalay na file o direktoryo. Kailan --source-list ay tinukoy, ang SOURCE
Tinutukoy ng argumento ang pangalan ng isang text file, na ang bawat linya ay alinman sa 1 o 2
mga path ng file na pinaghihiwalay ng whitespace. Ang unang landas ng file, ang pinagmulan, ay tumutukoy sa
path sa isang file o direktoryo upang makuha sa imahe ng WIM. Maaaring ito ay alinman
ganap o nauugnay sa kasalukuyang gumaganang direktoryo. Ang pangalawang landas ng file, kung
ibinigay, ay ang target at tinutukoy ang landas sa imahe ng WIM kung saan ang file na ito o
ang direktoryo ay isi-save bilang. Ang nangunguna at sumusunod na mga laslas sa target ay hindi pinapansin,
maliban kung ito ay ganap na binubuo ng mga slash (hal. "/"), na nagpapahiwatig na ang
ang direktoryo ay upang maging ugat ng imahe ng WIM. Kung aalisin, ang target na string
ang default ay pareho sa source string.

Ang isang halimbawa ng source list file ay ang sumusunod:

# Gawin ang imahe ng WIM mula sa direktoryo ng 'winpe'
winpe /

# Ipadala ang direktoryo ng 'overlay' sa '/overlay' sa imahe ng WIM
overlay / overlay

# I-overlay ang isang hiwalay na direktoryo nang direkta sa ugat ng imahe ng WIM.
/data/stuff /

Ang mga subdirectory sa WIM ay nilikha kung kinakailangan. Maramihang mga direktoryo ng pinagmulan ay maaaring
ibahagi ang parehong target, na nagpapahiwatig ng isang overlay. Kung sakaling magbunga ito ng a
nondirectory file na idinaragdag sa imahe ng WIM nang maraming beses, ang huling bersyon (bilang
nakalista sa source list file) ay nag-o-override sa anumang mas naunang bersyon.

Ang mga path ng file na naglalaman ng whitespace ay maaaring ma-quote na may alinman sa mga single quotes o double
quotes. Maaaring hindi nakatakas ang mga quote.

Mga linyang binubuo lamang ng whitespace at mga linyang nagsisimula sa '#' na sinusundan ng
hindi papansinin ang opsyonal na whitespace.

Bilang isang espesyal na kaso, kung SOURCE ay "-", ang listahan ng pinagmulan ay binabasa mula sa karaniwang input
sa halip na isang panlabas na file.

Hindi magagamit ang NTFS volume capture mode sa UNIX-like system --source-list,
dahil ang pagkuha lamang ng buong dami ng NTFS ang sinusuportahan.

--pipable
Gumawa ng "pipable" na WIM, na maaaring ganap na ilapat nang sunud-sunod, kabilang ang mula sa a
tubo. Ang isang imahe sa nagresultang WIM ay maaaring ilapat sa wimlib-imagex mag-aplay, alinman
karaniwan sa pamamagitan ng pagtukoy sa pangalan ng WIM file, o kasama ng wimlib-imagex mag-aplay - upang basahin ang
WIM mula sa karaniwang input. Tingnan mo wimlib-imagex mag-aplay(1) para sa higit pang mga detalye.

Para sa mga pagpapatakbo ng pagdaragdag, ang opsyong ito ay magreresulta sa isang buong muling pagtatayo ng WIM na gagawin
ito ay mabisa. Para sa mga pagpapatakbo ng pagkuha, ang na-capture na WIM ay ginawa lamang bilang piable.
Mag-ingat na ang mas maraming mga imahe na idinagdag mo sa isang pipible na WIM, hindi gaanong mahusay ang pagpi-pipe nito
ay magiging, dahil mas maraming hindi kinakailangang data ang ipapadala sa pamamagitan ng pipe.

Kapag ang wimlib ay lumikha ng isang pipible na WIM, maingat nitong inaayos ang mga bahagi ng
WIM upang mabasa ang mga ito nang sunud-sunod at gumawa din ng ilang iba pa
mga pagbabago. Bilang resulta, ang mga "pipable" na WIM na ito ay hindi magkasundo sa
Microsoft's software, kaya tandaan ito kung gagamitin mo ang mga ito. Kung gusto,
pwede mong gamitin wimlib-imagex optimize --hindi-pipable upang muling magsulat ng isang pipible na WIM bilang a
regular na WIM. (wimlib-imagex i-export nagbibigay din ng kakayahang mag-export ng mga larawan
mula sa isang pipible na WIM papunta sa isang non-pipable na WIM, o vice versa.)

Para sa karamihan, ang wimlib ay tumatakbo sa mga pipible na WIM nang malinaw. Maaari mong baguhin
mga ito, magdagdag o magtanggal ng mga larawan, mag-export ng mga larawan, at kahit na lumikha ng mga split pipible na WIM. Ang
Ang pangunahing kawalan ay ang pagsasama ay (kasalukuyang) hindi gaanong mahusay (--muling itayo is
palaging ipinahiwatig), at hindi rin sila tugma sa software ng Microsoft.

wimlib-imagex pagbihag at wimlib-imagex apendend ay maaaring magsulat ng isang pipible na WIM nang direkta
sa karaniwang output; ito ay awtomatikong ginagawa kung WIMFILE ay tinukoy bilang "-". (Sa
kaso, --pipable ay ipinapalagay.)

--hindi-pipable
Tiyaking ang resultang WIM ay nasa normal, non-pipable na format ng WIM. Ito ang
default para sa wimlib-imagex pagbihag, maliban kapag sumusulat sa karaniwang output (WIMFILE
tinukoy bilang "-"), at para din sa wimlib-imagex apendend, maliban sa pagdaragdag sa isang WIM
pipible na yan.

--update-ng=[WIMFILE:]IMAGE
Ipinapahayag na ang larawang kinukunan o idinagdag mula sa SOURCE ay halos pareho sa
ang umiiral na imahe IMAGE in WIMFILE, ngunit nakunan sa ibang pagkakataon, posibleng
na may ilang mga pagbabago sa intervening time. Ito ay dinisenyo upang magamit sa
incremental backups ng parehong filesystem o directory tree. IMAGE ay maaaring isang
1-based na index o pangalan ng isang umiiral na larawan sa WIMFILE. Maaari rin itong maging negatibo
integer upang i-index pabalik sa mga imahe (hal. -1 ay nangangahulugang ang huling umiiral na larawan
in WIMFILE).

Kapag ibinigay ang opsyong ito, ang pagkuha o pagdaragdag ng bagong larawan ay magiging
na-optimize sa pamamagitan ng hindi pagbabasa ng mga file na, batay sa metadata gaya ng mga timestamp, lalabas
hindi na nabago dahil na-archive ang mga ito sa umiiral na IMAGE. Harang
pagmamanipula ng mga timestamp, ang pagpipiliang ito ay nakakaapekto lamang sa pagganap at hindi nagbabago
ang nagresultang imahe ng WIM.

Gaya ng ipinapakita, ang buong syntax para sa argumento sa opsyong ito ay tukuyin ang WIM
file, isang colon, at ang imahe; halimbawa, "--update-of mywim.wim:1". Gayunpaman, ang
Maaaring tanggalin ang WIM file at colon, kung saan ang WIM file ay magiging default sa
WIM file na idinaragdag para sa mga pagpapatakbo ng append, o ang WIM file kung saan ang isang delta
ay kinukuha (kung --delta-mula sa ay tinukoy nang eksaktong isang beses) para sa pagkuha
operasyon.

--delta-mula sa=WIMFILE
para wimlib-imagex pagbihag lamang: makuha ang bagong WIM bilang isang "delta" mula sa WIMFILE. Anumang
ang mga stream na karaniwang kailangang i-archive sa bagong WIM ay aalisin kung sila
ay naroroon na sa WIMFILE kung saan nakabatay ang delta. Ang bagong WIM
maglalaman pa rin ng buong kopya ng metadata ng larawan, ngunit ito ay karaniwang isang
maliit na bahagi ng kabuuang sukat ng isang WIM.

Maaaring tukuyin ang opsyong ito ng maraming beses, kung saan ang resultang delta WIM
maglalaman lamang ng mga stream na wala sa alinman sa mga tinukoy na base WIM.

Upang gumana sa resultang delta WIM gamit ang iba pang mga utos tulad ng wimlib-imagex
mag-aplay, dapat mong tukuyin ang delta WIM bilang WIM file upang gumana, ngunit gayundin
sumangguni sa (mga) batayang WIM gamit ang --ref opsyon. Mag-ingat: upang mapanatili ang nararapat
gumagana ng delta WIM, maaari ka lamang magdagdag, hindi magtanggal, mga file at larawan sa
base WIM(s) kasunod ng pagkuha ng isang delta mula dito.

--delta-mula sa maaaring isama sa --update-ng para mapabilis ang pagkuha ng a
delta WIM.

Bilang halimbawa, isaalang-alang ang sumusunod na pagkakasunud-sunod ng pag-backup at pagpapanumbalik:

(paunang backup)

$ wimcapture /some/directory bkup-base.wim

(pagkalipas ng ilang araw, lumikha ng pangalawang backup bilang delta mula sa una)

$ wimcapture /some/directory bkup-2013-08-20.dwm \
--update-ng bkup-base.wim:-1 --delta-mula sa bkup-base.wim

(ibinabalik ang pangalawang backup)

$ wimapply bkup-2013-08-20.dwm --ref=bkup-base.wim 1 \
/some/directory

Gayunpaman, tandaan na bilang isang kahalili sa pagkakasunud-sunod sa itaas na gumamit ng delta WIM,
ang pangalawang backup ay maaaring idinagdag lamang sa WIM bilang bagong imahe gamit
wimlib-imagex apendend. Ang mga Delta WIM ay dapat gamitin lamang kung nais nitong ibase ang
backup o mga imahe sa isang hiwalay, malaking file na bihirang mabago.

Tandaan: hindi tulad ng mga "pipable" na WIM (ginawa gamit ang --pipable opsyon), "delta" na mga WIM
(nilikha gamit ang --delta-mula sa opsyon) ay katugma sa software ng Microsoft.
Halimbawa, maaari mong gamitin ang /ref na opsyon ng ImageX upang i-reference ang (mga) base WIM,
katulad sa itaas.

Karagdagang tala: wimlib-imagex ay sapat na pangkalahatan na maaari mong pagsamahin
--pipable at --delta-mula sa upang lumikha ng mga pipible delta WIM. Sa ganitong mga kaso, ang base
Ang (mga) WIM ay dapat makuha bilang pipible gayundin ang delta WIM, at kapag nag-aaplay ng isang
larawan, ang (mga) base WIM ay dapat ipadala sa ibabaw ng pipe pagkatapos ng delta WIM.

--wimboot
Markahan ang larawan bilang WIMBoot-compatible. Tingnan ang dokumentasyon ng Microsoft para sa higit pa
impormasyon tungkol sa WIMBoot. Itatakda ng opsyong ito, bilang default, ang uri ng compression
sa XPRESS at ang laki ng tipak sa 4096 bytes; ang mga ito, gayunpaman, ay ma-override pa rin
sa pamamagitan ng --compress at --laki ng tipak mga parameter, ayon sa pagkakabanggit. Bilang karagdagan, ito
Ang opsyon ay, bilang default, itatakda ang configuration file sa
SOURCE\Windows\System32\WimBootCompress.ini kung naroroon at naa-access; gayunpaman, ito
maaari pa ring ma-override sa pamamagitan ng --config parameter

--hindi ligtas-compact
Tingnan ang dokumentasyon para sa opsyong ito sa wimlib-imagex-optimize Na (1).

--snapshot
EXPERIMENTAL: lumikha ng pansamantalang filesystem snapshot ng source directory at
makuha ang mga file mula dito. Sa kasalukuyan, ang opsyong ito ay sinusuportahan lamang sa Windows,
kung saan ginagamit nito ang Volume Shadow Copy Service (VSS). Gamit ang pagpipiliang ito, magagawa mo
lumikha ng pare-parehong backup ng dami ng system ng tumatakbong Windows system nang wala
nagkakaproblema sa mga naka-lock na file. Para maging matagumpay ang snapshot ng VSS
nilikha, wimlib-imagex dapat patakbuhin bilang Administrator, at hindi ito maaaring patakbuhin
WoW64 mode (ibig sabihin, kung ang Windows ay 64-bit, kung gayon wimlib-imagex dapat ay 64-bit din).

NOTA

wimlib-imagex apendend ay hindi sumusuporta sa pagdaragdag ng isang imahe sa isang split WIM.

Maliban kapag gumagamit --hindi ligtas-compact, ligtas na ipalaglag ang a wimlib-imagex apendend utos
sa gitna; gayunpaman, pagkatapos gawin ito, inirerekumenda na tumakbo wimlib-imagex
optimize upang alisin ang anumang data na idinagdag sa pisikal na WIM file ngunit hindi pa
isinama sa istruktura ng WIM, maliban kung ang WIM ay ganap na itinayong muli (hal.
sa --muling itayo), kung saan dapat mong tanggalin ang pansamantalang file na natitira.

wimlib-imagex lumilikha ng mga WIM na katugma sa software ng Microsoft (WIMGAPI, ImageX, DISM),
na may ilang mga babala:

· Kasama wimlib-imagex sa mga sistemang tulad ng UNIX, posible na lumikha ng isang imahe ng WIM
naglalaman ng mga file na may mga pangalan na naiiba lamang sa kaso, o mga file na may mga pangalan na naglalaman ng
mga character na ':', '*', '?', '"', '<', '>', '|', o '\', na may bisa sa POSIX-
mga sumusunod na filesystem ngunit hindi Windows. Maging babala na ang mga naturang file ay hindi magiging
na-extract bilang default ng bersyon ng Windows ng wimlib-imagex, at (mas masahol pa)
Ang ImageX ng Microsoft ay maaaring malito sa pamamagitan ng mga naturang pangalan at huminto sa pag-extract ng imahe sa kalagitnaan
sa pamamagitan ng. (Marahil ay nararapat na ituro na ang sariling default na filesystem ng Windows,
Ang NTFS, ay sumusuporta sa mga character na ito, kahit na ang Windows ay hindi!)

· Ang mga pipable na WIM ay hindi tugma sa software ng Microsoft. Ang mga pipable na WIM ay nilikha
kung WIMFILE ay tinukoy bilang "-" (karaniwang output) o kung ang --pipable bandila noon
tinukoy.

· Nakuha ang mga WIM na may hindi default na laki ng tipak (na may --laki ng tipak opsyon) o bilang solid
archive (kasama ang --matibay opsyon) o may LZMS compression (na may --compress=LZMS o
--compress=recovery) ay may iba't ibang antas ng compatibility sa software ng Microsoft.
Sa pangkalahatan, mas tugma ang mga pinakabagong bersyon ng software ng Microsoft.

HALIMBAWA

Unang halimbawa: Gumawa ng bagong WIM 'mywim.wim' na may LZX ("maximum") compression na
naglalaman ng isang nakunan na imahe ng puno ng direktoryo na 'somedir'. Tandaan na kailangan ng pangalan ng larawan
hindi tinukoy at magiging default sa 'somedir':

wimlib-imagex capture somedir mywim.wim

o, kung ang wimcapture hard link o batch file ay na-install, ang pinaikling form ay maaaring
gamitin:

wimcapture somedir mywim.wim

Ang natitirang mga halimbawa ay gagamit ng mahabang anyo, gayunpaman. Susunod, dugtungan ang larawan ng a
ibang puno ng direktoryo sa WIM na nilikha sa itaas:

wimlib-imagex magdagdag ng isa pangdir mywim.wim

Sapat na madali, at ang mga halimbawa sa itaas ng mga puno ng direktoryo ng imaging ay gumagana sa parehong katulad ng UNIX
mga system at Windows. Susunod, kumuha ng WIM na may ilang mga hindi default na opsyon, kabilang ang
XPRESS ("mabilis") compression, isang talahanayan ng integridad, walang gulo sa ganap na simbolikong mga link,
at isang pangalan ng larawan at paglalarawan:

wimlib-imagex capture somedir mywim.wim --compress=fast \
--check --norpfix "Ilang Pangalan" "Ilang Paglalarawan"

Kunin ang isang buong volume ng NTFS sa isang bagong WIM file at pangalanan ang imahe na "Windows 7". Naka-on
UNIX-like system, ito ay nangangailangan ng paggamit ng espesyal na mode na inilarawan sa NTFS VOLUME KARAPATAN
(UNIX) saan SOURCE ay isang file o block device na naglalaman ng NTFS filesystem:

wimlib-imagex capture /dev/sda2 windows7.wim "Windows 7"

o, sa Windows, upang makuha ang isang buong dami ng NTFS kailangan mong tukuyin ang ugat
direktoryo ng naka-mount na volume, halimbawa:

wimlib-imagex capture E:\ windows7.wim "Windows 7"

Pareho sa halimbawa sa itaas sa pagkuha ng NTFS volume mula sa wimlib-imagex tumatakbo sa isang UNIX-
tulad ng system, ngunit makuha ang WIM sa format na "pipable" na partikular sa wimlib na maaaring i-pipe
sa wimlib-imagex mag-aplay:

wimlib-imagex capture /dev/sda2 windows7.wim "Windows 7" \
--pipable

Pareho sa itaas, ngunit sa halip na isulat ang pipible na WIM sa file na "windows7.wim", isulat ito
direkta sa karaniwang output sa pamamagitan ng isang pipe sa ilang iba pang mga programa "someprog", na kung saan
maaaring, halimbawa, ay isang programa o script na nag-stream ng data sa isang server. Tandaan na
--pipable hindi kailangang tahasang tukuyin kapag gumagamit ng karaniwang output bilang "file" ng WIM:

wimlib-imagex capture /dev/sda2 - "Windows 7" | someprog

Gumamit ng wimlib-imagex-append online gamit ang mga serbisyo ng onworks.net