wimlib-imagex-append - ອອນລາຍໃນຄລາວ

ໂຄງການ:

NAME

wimlib-imagex-capture, wimlib-imagex-append - ສ້າງ ຫຼືເພີ່ມຮູບ WIM

ສະຫຼຸບສັງລວມ

wimlib-imagex ຈັບ ແຫຼ່ງຂໍ້ມູນ WIMFILE [IMAGE_NAME [IMAGE_DESCRIPTION]] [ທາງເລືອກ... ]
wimlib-imagex ເພີ່ມເຕີມ ແຫຼ່ງຂໍ້ມູນ WIMFILE [IMAGE_NAME [IMAGE_DESCRIPTION]] [ທາງເລືອກ... ]

ລາຍລະອຽດ

ໄດ້ wimlib-imagex ຈັບ ແລະ wimlib-imagex ເພີ່ມເຕີມ ຄໍາສັ່ງສ້າງ Windows Imaging (WIM)
ຮູບພາບຈາກຕົ້ນໄມ້ໄດເລກະທໍລີ. ໄດ້ wimlib-imagex ຈັບ ຄໍາສັ່ງສ້າງໄຟລ໌ WIM ໃຫມ່
ມີ​ຮູບ​ພາບ captured ໄດ້​, ໃນ​ຂະ​ນະ​ທີ່​ wimlib-imagex ເພີ່ມເຕີມ ຄໍາ​ສັ່ງ​ເພີ່ມ​ເຕີມ​ທີ່​ຈັບ​ໄດ້​
ຮູບພາບໄປຫາໄຟລ໌ WIM ທີ່ມີຢູ່ແລ້ວ. ຄໍາສັ່ງເຫຼົ່ານີ້ແມ່ນຍັງສາມາດໃຊ້ໄດ້ພຽງແຕ່ wimcapture ແລະ
wimappend ຖ້າການເຊື່ອມຕໍ່ແຂງທີ່ເຫມາະສົມຫຼືໄຟລ໌ batch ຖືກຕິດຕັ້ງ.

ຂໍ້​ມູນ​ພື້ນ​ຖານ​: ຮູບ​ພາບ WIM ເປັນ​ຕົ້ນ​ໄມ້​ລະ​ບົບ​ເອ​ກະ​ລາດ​ໃນ​ໄຟລ​໌ WIM​. A WIM
ໄຟລ໌ອາດມີຈໍານວນຮູບພາບແຍກຕ່າງຫາກ. ໄຟລ໌ WIM ແມ່ນແບບຕົວຢ່າງດຽວກັບ
ກ່ຽວກັບຂໍ້ມູນໄຟລ໌, ດັ່ງນັ້ນໄຟລ໌ຈະຖືກເກັບໄວ້ພຽງແຕ່ຫນຶ່ງຄັ້ງໃນ WIM ທັງຫມົດ, ບໍ່ວ່າຈະເປັນ
ຮູບ​ພາບ​ທີ່​ໄຟລ​໌​ປາ​ກົດ​ຢູ່​ໃນ​ຈໍາ​ນວນ​ຫຼາຍ​ປານ​ໃດ​.

ແຫຼ່ງຂໍ້ມູນ ລະບຸສະຖານທີ່ຂອງໄຟລ໌ເພື່ອສ້າງຮູບພາບ WIM ໃຫມ່ຈາກ. ຖ້າ ແຫຼ່ງຂໍ້ມູນ is
ໄດເລກະທໍລີ, ຮູບພາບ WIM ຖືກຈັບຈາກໄດເລກະທໍລີນັ້ນ (ເບິ່ງ ທິດທາງ ຮູບພາບ (UNIX)
or ທິດທາງ ຮູບພາບ (ປ່ອງຢ້ຽມ)). ອີກທາງເລືອກ, ຖ້າ --source-list ທາງເລືອກແມ່ນ
ລະບຸ, ແຫຼ່ງຂໍ້ມູນ ຖືກຕີຄວາມວ່າເປັນໄຟລ໌ທີ່ຕົນເອງສະຫນອງບັນຊີລາຍຊື່ຂອງໄຟລ໌ແລະ
ໄດເລກະທໍລີທີ່ຈະລວມຢູ່ໃນຮູບພາບ WIM ໃຫມ່. ອີກທາງເລືອກ, ພຽງແຕ່ຢູ່ໃນ UNIX-like
ລະບົບ, ຖ້າ ແຫຼ່ງຂໍ້ມູນ ເປັນໄຟລ໌ປົກກະຕິຫຼືອຸປະກອນຕັນ, ມັນຖືກຕີຄວາມວ່າປະລິມານ NTFS
ຈາກຮູບພາບ WIM ຈະຖືກບັນທຶກໄວ້ໂດຍໃຊ້ libntfs-3g (ເບິ່ງ NTFS VOLUME ຮູບພາບ
(UNIX)).

IMAGE_NAME ແລະ IMAGE_DESCRIPTION ລະບຸຊື່ ແລະລາຍລະອຽດເພື່ອໃຫ້ WIM ໃໝ່
ຮູບ. ຖ້າ IMAGE_NAME ບໍ່​ໄດ້​ລະ​ບຸ​ໄວ້​, ມັນ​ເປັນ​ຄ່າ​ເລີ່ມ​ຕົ້ນ​ຂອງ​ຊື່​ພື້ນ​ຖານ (ບໍ່​ລວມ​ເອົາ​ເສັ້ນ​ທາງ​ໄປ​
ໄດເລກະທໍລີຫຼັກ) ຂອງ ແຫຼ່ງຂໍ້ມູນ, ແຕ່ຖ້າຊື່ນີ້ມີຢູ່ໃນ WIMFILE, ເປັນ suffix ເປັນເອກະລັກ
ຖືກເພີ່ມ. ຖ້າບໍ່ດັ່ງນັ້ນ, IMAGE_NAME ຕ້ອງເປັນຊື່ທີ່ບໍ່ມີຢູ່ແລ້ວເປັນ
ຮູບພາບໃນ WIMFILE, ຫຼືສະຕຣິງຫວ່າງເປົ່າເພື່ອສ້າງຮູບພາບທີ່ບໍ່ມີຊື່. ຖ້າ
IMAGE_DESCRIPTION ບໍ່ໄດ້ລະບຸ, ບໍ່ມີຄໍາອະທິບາຍໃຫ້ຮູບພາບໃຫມ່.

ເປັນກໍລະນີພິເສດ, ຖ້າ WIMFILE ແມ່ນ "-", ໄດ້ --pipable ທາງເລືອກແມ່ນສົມມຸດແລະໄຟລ໌ WIM ແມ່ນ
ຂຽນເປັນຜົນຜະລິດມາດຕະຖານໃນຮູບແບບ pipable ພິເສດ. ເບິ່ງເອກະສານສໍາລັບ
--pipable ສໍາລັບລາຍລະອຽດເພີ່ມເຕີມ.

ທິດທາງ ຮູບພາບ (UNIX)

ພາກນີ້ ເອກະສານວິທີການ wimlib-imagex ບັນທຶກໄຟລ໌ຈາກຕົ້ນໄມ້ໄດເລກະທໍລີທີ່ຄ້າຍຄືກັບ UNIX
ລະບົບ. ເບິ່ງ ທິດທາງ ຮູບພາບ (ປ່ອງຢ້ຽມ) ສໍາລັບເອກະສານທີ່ສອດຄ້ອງກັນສໍາລັບ Windows.

ໃນລະບົບຄ້າຍ UNIX, ເມື່ອ ແຫຼ່ງຂໍ້ມູນ ກໍານົດໄດເລກະທໍລີຫຼືການເຊື່ອມຕໍ່ສັນຍາລັກກັບໄດເລກະທໍລີ,
ຮູບພາບ WIM ຈະຖືກບັນທຶກໄວ້ຈາກຕົ້ນໄມ້ໄດເລກະທໍລີທີ່ຮາກຖານຢູ່ໃນໄດເລກະທໍລີນີ້. ນີ້
ໄດເລກະທໍລີສາມາດຢູ່ໃນປະເພດຂອງລະບົບໄຟລ໌ໃດກໍ່ຕາມ, ແລະ mountpoints ແມ່ນປະຕິບັດຕາມ recursively. ໃນ
ຮູບແບບນີ້, wimlib ຈະເກັບຮັກສາຂໍ້ມູນປະເພດຕໍ່ໄປນີ້:

·ລາຍຊື່ແລະໄຟລ໌ປົກກະຕິ, ແລະເນື້ອໃນຂອງໄຟລ໌ປົກກະຕິ

·ການເຊື່ອມຕໍ່ຍາກ

·​ການ​ເຊື່ອມ​ຕໍ່​ສັນ​ຍາ​ລັກ (ແປ losslessly ກັບ Windows reparse ຈຸດ​)

·ເວລາດັດແກ້ຫຼ້າສຸດ (mtime) ແລະຄັ້ງສຸດທ້າຍ (atime) ທີ່ມີ 100 nanosecond
ຄວາມຫຼາກຫຼາຍ

· ກັບ --unix-data: ເຈົ້າຂອງ UNIX, ກຸ່ມ, ແລະໂຫມດ

· ກັບ --unix-data: ໂນດອຸປະກອນ, FIFOs, ແລະຊັອກເກັດໂດເມນ UNIX

ບໍ່ມີການສະຫນັບສະຫນູນສໍາລັບການເກັບຮັກສາຄຸນລັກສະນະຂະຫຍາຍ (ເຊັ່ນ: ປ້າຍຄວາມປອດໄພ SELinux ແລະ
POSIX ACLs). ຈື່ໄວ້ວ່າເວລາປ່ຽນສະຖານະສຸດທ້າຍ (ctime) ບໍ່ໄດ້ຖືກເກັບໄວ້.

ຫມາຍເຫດ Pedantic: ການຈໍາກັດຂອງຮູບແບບ WIM ປ້ອງກັນກໍລະນີທີ່ຜິດປົກກະຕິທີ່ດຽວ
ໄຟລ໌ເຊື່ອມຕໍ່ສັນຍາລັກຕົວມັນເອງມີຫຼາຍຊື່ (ການເຊື່ອມຕໍ່ຍາກ); ໃນກໍລະນີດັ່ງກ່າວນີ້, ແຕ່ລະຄົນ
ການເຊື່ອມຕໍ່ສັນຍາລັກຖືກເກັບໄວ້ເປັນໄຟລ໌ເອກະລາດ.

NTFS VOLUME ຮູບພາບ (UNIX)

ພາກນີ້ ເອກະສານວິທີການ wimlib-imagex ບັນທຶກໄຟລ໌ໂດຍກົງຈາກຮູບພາບປະລິມານ NTFS
ໃນລະບົບຄ້າຍ UNIX.

ໃນລະບົບທີ່ຄ້າຍຄື UNIX, ຮູບແບບການຈັບພາບພິເສດຈະຖືກໃສ່ເມື່ອ ແຫຼ່ງຂໍ້ມູນ ແມ່ນປົກກະຕິ
ໄຟລ໌ ຫຼືອຸປະກອນບລັອກ. ໃນ​ຮູບ​ແບບ​ນີ້​, ແຫຼ່ງຂໍ້ມູນ ຖືວ່າເປັນປະລິມານ ຫຼືປະລິມານ NTFS
ຮູບ​ພາບ​, ແລະ​ wimlib-imagex ຈະບັນທຶກຮູບພາບ WIM ທີ່ມີເນື້ອໃນເຕັມຂອງ NTFS
ປະລິມານ, ລວມທັງຂໍ້ມູນສະເພາະ NTFS. ນີ້ແມ່ນເຮັດໄດ້ໂດຍໃຊ້ libntfs-3g.

ໃຫ້ສັງເກດວ່າຮູບແບບການຈັບປະລິມານ NTFS ແມ່ນ ບໍ່ ເຂົ້າໄປຖ້າ ແຫຼ່ງຂໍ້ມູນ ແມ່ນໄດເລກະທໍລີ, ເຖິງແມ່ນວ່າເປັນ
ລະບົບໄຟລ໌ NTFS ຖືກຕິດຕັ້ງຢູ່ ແຫຼ່ງຂໍ້ມູນ ການນໍາໃຊ້ ntfs-3g. ທ່ານຕ້ອງລະບຸປະລິມານ NTFS
ຕົວຂອງມັນເອງ (ແລະມັນຕ້ອງໄດ້ຮັບການ unmounted, ແລະທ່ານຕ້ອງໄດ້ຮັບການອະນຸຍາດໃຫ້ອ່ານຈາກມັນ).

ໂຫມດການຈັບປະລິມານ NTFS ພະຍາຍາມເກັບກໍາຂໍ້ມູນແລະ metadata ຫຼາຍເທົ່າທີ່ເປັນໄປໄດ້,
ລວມທັງ:

· ກະແສຂໍ້ມູນທັງໝົດຂອງໄຟລ໌ທີ່ບໍ່ໄດ້ເຂົ້າລະຫັດທັງໝົດ, ລວມທັງກະແສຂໍ້ມູນທີ່ບໍ່ມີຊື່ເຊັ່ນກັນ
ເປັນກະແສຂໍ້ມູນທີ່ມີຊື່ທັງໝົດ.

· ຈຸດ Reparse, ລວມທັງການເຊື່ອມຕໍ່ສັນຍາລັກ, ຈຸດແຍກ, ແລະຈຸດ reparse ອື່ນໆ.

· ການ​ສ້າງ​ໄຟລ​໌​ແລະ​ລະ​ບົບ​, ການ​ເຂົ້າ​ເຖິງ​, ແລະ​ການ​ດັດ​ແກ້​ເວ​ລາ​, ການ​ນໍາ​ໃຊ້​ພື້ນ​ເມືອງ​
ຄວາມລະອຽດ NTFS 100 ນາໂນວິນາທີ.

· ຕົວອະທິບາຍຄວາມປອດໄພຂອງ Windows, ລວມທັງອົງປະກອບທັງໝົດ (ເຈົ້າຂອງ, ກຸ່ມ, DACL, ແລະ SACL).

· DOS/Windows file ທຸງຄຸນລັກສະນະ.

·ຊື່ທັງຫມົດຂອງໄຟລ໌ທັງຫມົດ, ລວມທັງຊື່ໃນ Win32 namespace, DOS namespace,
Win32+DOS namespace, ແລະ POSIX namespace. ນີ້ປະກອບມີການເຊື່ອມຕໍ່ຍາກ.

ຢ່າງໃດກໍຕາມ, ຂໍ້ຈໍາກັດຕົ້ນຕໍຂອງໂຫມດການຈັບປະລິມານ NTFS ນີ້ແມ່ນ:

· ໄຟລ໌ທີ່ຖືກເຂົ້າລະຫັດຖືກຍົກເວັ້ນໂດຍຄ່າເລີ່ມຕົ້ນ. ເຖິງແມ່ນວ່າ libntfs-3g ສາມາດອ່ານຂໍ້ມູນຂອງເຂົາເຈົ້າໄດ້,
ພວກມັນຈໍາເປັນຕ້ອງຖືກເກັບໄວ້ໃນໄຟລ໌ WIM ໃນຮູບແບບພິເສດທີ່ wimlib ຍັງບໍ່ທັນໄດ້
ສະຫນັບສະຫນູນ (ຍົກເວັ້ນໃນ Windows, ບ່ອນທີ່ wimlib ສາມາດປະຕິບັດຂໍ້ມູນເປັນ opaque ແລະມືມັນອອກ
ກັບຟັງຊັນ API ທີ່ເຫມາະສົມ).

· ຄຸນ​ລັກ​ສະ​ນະ sparse ໃນ​ໄຟລ​໌ sparse ຈະ​ໄດ້​ຮັບ​ການ​ບັນ​ທຶກ​ໄວ້​, ແຕ່​ຂໍ້​ມູນ​ທີ່​ເກັບ​ຮັກ​ສາ​ໄວ້​ຈະ​ເປັນ​
ຂໍ້ມູນເຕັມຂອງໄຟລ໌ແທນທີ່ຈະເປັນຂໍ້ມູນ "sparse". (ຢ່າງໃດກໍ່ຕາມ, ຂໍ້ມູນແມ່ນຫົວຂໍ້
ກັບການບີບອັດຮູບແບບ WIM.)

ທິດທາງ ຮູບພາບ (ປ່ອງຢ້ຽມ)

ໃນ Windows, wimlib-imagex ຈັບ ແລະ wimlib-imagex ເພີ່ມເຕີມ ໂດຍພື້ນຖານແລ້ວສະຫນັບສະຫນູນ Windows-
ຂໍ້ມູນສະເພາະ ແລະ NTFS ສະເພາະ. ດັ່ງນັ້ນເຂົາເຈົ້າປະຕິບັດຄ້າຍຄືກັນກັບທີ່ສອດຄ້ອງກັນ
ຄໍາສັ່ງຂອງ Microsoft's ImageX ຫຼື DISM. ສໍາລັບຜົນໄດ້ຮັບທີ່ດີທີ່ສຸດ, ໄດເລກະທໍລີທີ່ຖືກຈັບ
ຄວນຈະຢູ່ໃນປະລິມານ NTFS ແລະ wimlib-imagex ຄວນດໍາເນີນການດ້ວຍສິດທິພິເສດຂອງຜູ້ບໍລິຫານ;
ແນວໃດກໍ່ຕາມ, ລະບົບໄຟລ໌ທີ່ບໍ່ແມ່ນ NTFS ແລະເຮັດວຽກໂດຍບໍ່ມີສິດທິຜູ້ເບິ່ງແຍງລະບົບແມ່ນຄືກັນ
ສະຫນັບສະຫນູນ.

ໃນ Windows, wimlib-imagex ຈັບ ແລະ wimlib-imagex ເພີ່ມເຕີມ ພະຍາຍາມເກັບຂໍ້ມູນຫຼາຍເທົ່າແລະ
metadata ທີ່ເປັນໄປໄດ້, ລວມທັງ:

· ກະແສຂໍ້ມູນທັງໝົດຂອງໄຟລ໌ທັງໝົດ.

·​ຈຸດ Reparse​, ລວມ​ທັງ​ການ​ເຊື່ອມ​ຕໍ່​ສັນ​ຍາ​ລັກ​, ຈຸດ​ແຍກ​, ແລະ​ຈຸດ reparse ອື່ນໆ​,
ຖ້າສະຫນັບສະຫນູນໂດຍລະບົບໄຟລ໌ແຫຼ່ງ. (ຫມາຍເຫດ: ເບິ່ງ --rpfix ແລະ --norpfix ສໍາລັບການ
ເອກະສານກ່ຽວກັບວິທີການເຊື່ອມໂຍງສັນຍາລັກ ແລະຈຸດເຊື່ອມຕໍ່ຢ່າງແທ້ຈິງຖືກຈັບ.)

· ການ​ສ້າງ​ໄຟລ​໌​ແລະ​ລະ​ບົບ​, ການ​ເຂົ້າ​ເຖິງ​, ແລະ​ການ​ດັດ​ແກ້​ເວ​ລາ​ສະ​ແຕມ​. ເຫຼົ່ານີ້ແມ່ນເກັບຮັກສາໄວ້
ດ້ວຍຄວາມລະອຽດເວລາເດີມຂອງ Windows NT ຂອງ 100 nanoseconds.

·ຕົວອະທິບາຍຄວາມປອດໄພ, ຖ້າສະຫນັບສະຫນູນໂດຍລະບົບໄຟລ໌ແຫຼ່ງແລະ --no-acls ບໍ່​ແມ່ນ
ລະບຸ. ຢ່າງໃດກໍຕາມ, ລະວັງວ່າເວັ້ນເສຍແຕ່ --strict-acls ຖືກກໍານົດ, ຄວາມປອດໄພ
ຄໍາອະທິບາຍສໍາລັບແຕ່ລະໄຟລ໌ຫຼືໄດເລກະທໍລີອາດຈະຖືກລະເວັ້ນຫຼືພຽງແຕ່ບາງສ່ວນ
captured ຖ້າ​ຫາກ​ວ່າ​ຜູ້​ໃຊ້​ບໍ່​ມີ​ການ​ອະ​ນຸ​ຍາດ​ໃຫ້​ເຂົາ​ເຈົ້າ​ອ່ານ​, ຊຶ່ງ​ສາ​ມາດ​ເປັນ​ບັນ​ຫາ​ຖ້າ​ຫາກ​ວ່າ​
wimlib-imagex ແມ່ນດໍາເນີນການເປັນທີ່ບໍ່ແມ່ນຜູ້ບໍລິຫານ.

· ຄຸນ​ລັກ​ສະ​ນະ​ຂອງ​ໄຟລ​໌​, ລວມ​ທັງ​ເຊື່ອງ​ໄວ້​, sparse​, compressed​, encrypted​, ແລະ​ອື່ນໆ​ເຂົ້າ​ລະ​ຫັດ​
ໄຟລ໌ຈະຖືກເກັບໄວ້ໃນຮູບແບບທີ່ຖືກເຂົ້າລະຫັດແທນທີ່ຈະເປັນຂໍ້ຄວາມທໍາມະດາ. ໂປ່ງໃສ
ໄຟລ໌ທີ່ຖືກບີບອັດຈະຖືກອ່ານແບບບໍ່ຖືກບີບອັດ ແລະຖືກເກັບໄວ້ໂດຍຕົວຂອງ WIM
ການບີບອັດ. ບໍ່ມີການຈັດການພິເສດສໍາລັບການເກັບຮັກສາໄຟລ໌ sparse, ແຕ່ພວກເຂົາເຈົ້າແມ່ນ
ມີແນວໂນ້ມທີ່ຈະບີບອັດເປັນຂະຫນາດນ້ອຍ.

· ຊື່ DOS (8.3) ຊື່ຂອງໄຟລ໌; ແນວໃດກໍ່ຕາມ, ຄວາມລົ້ມເຫຼວທີ່ຈະອ່ານພວກມັນບໍ່ໄດ້ຖືກພິຈາລະນາ
ສະ​ພາບ​ຄວາມ​ຜິດ​ພາດ​.

· ການ​ເຊື່ອມ​ຕໍ່​ຍາກ​, ຖ້າ​ຫາກ​ວ່າ​ສະ​ຫນັບ​ສະ​ຫນູນ​ໂດຍ​ລະ​ບົບ​ໄຟລ​໌​ແຫຼ່ງ​.

ບໍ່ມີການສະຫນັບສະຫນູນສໍາລັບການເກັບຮັກສາຄຸນລັກສະນະຂະຫຍາຍ NTFS ແລະ ID ວັດຖຸ.

ຂະບວນການຈັບແມ່ນປີ້ນກັບກັນ, ຕັ້ງແຕ່ເວລາໃດ wimlib-imagex ນໍາໃຊ້ (ໃນ Windows) ສານສະກັດຈາກ
ຮູບພາບ WIM ທີ່ຖືກຈັບ, ມັນຈະສະກັດຂໍ້ມູນທັງຫມົດຂ້າງເທິງ, ຢ່າງຫນ້ອຍໄປຫາ
ຂອບເຂດທີ່ສະຫນັບສະຫນູນໂດຍລະບົບໄຟລ໌ປາຍທາງ.

ຫມາຍເຫດ Pedantic: ເນື່ອງຈາກ Windows ບໍ່ເຂົ້າກັນໄດ້ຢ່າງເຕັມສ່ວນກັບລະບົບໄຟລ໌ຂອງຕົນເອງ (NTFS), ເປີດ
Windows wimlib ບໍ່ສາມາດເກັບໄຟລ໌ບາງອັນທີ່ອາດມີຢູ່ໃນລະບົບໄຟລ໌ NTFS ທີ່ຖືກຕ້ອງແຕ່
ບໍ່ສາມາດເຂົ້າເຖິງ Windows API ໄດ້, ຕົວຢ່າງສອງໄຟລ໌ທີ່ມີຊື່ແຕກຕ່າງກັນພຽງແຕ່ຢູ່ໃນ
ກໍ​ລະ​ນີ​ທີ່​ຢູ່​ໃນ​ລະ​ບົບ​ດຽວ​ກັນ​, ຫຼື​ໄຟລ​໌​ທີ່​ມີ​ຊື່​ປະ​ກອບ​ດ້ວຍ​ຕົວ​ອັກ​ສອນ​ບາງ​ຢ່າງ​ພິ​ຈາ​ລະ​ນາ​
ບໍ່ຖືກຕ້ອງໂດຍ Windows. ຖ້າ​ຫາກ​ວ່າ​ທ່ານ​ມີ​ບັນ​ຫາ​ໃນ​ການ​ເກັບ​ໄຟລ​໌​ດັ່ງ​ກ່າວ​ພິ​ຈາ​ລະ​ນາ​ການ​ນໍາ​ໃຊ້​ NTFS
VOLUME ຮູບພາບ (UNIX) ໂໝດຈາກ Linux.

OPTIONS

-ເປີດ
ລະບຸວ່າຮູບພາບໃໝ່ຈະຖືກສ້າງເປັນຮູບທີ່ສາມາດເປີດໄດ້ຂອງ WIM archive.

--ກວດ​ສອບ
ສໍາລັບການ wimlib-imagex ເພີ່ມເຕີມ, ກ່ອນທີ່ຈະດໍາເນີນການປະຕິບັດການເພີ່ມເຕີມ, ໃຫ້ກວດເບິ່ງ
ຄວາມຊື່ສັດຂອງ WIMFILE ຖ້າມີຕາຕະລາງຄວາມສົມບູນ. ນອກຈາກນັ້ນ, ປະກອບມີ
ຕາຕະລາງຄວາມສົມບູນໃນໄຟລ໌ WIM ໃໝ່ (wimlib-imagex ຈັບ) ຫຼືໄຟລ໌ WIM ທີ່ຖືກແກ້ໄຂ
(wimlib-imagex ເພີ່ມເຕີມ). ຖ້າຕົວເລືອກນີ້ບໍ່ໄດ້ຖືກລະບຸ, ບໍ່ມີຕາຕະລາງຄວາມສົມບູນ
ລວມຢູ່ໃນໄຟລ໌ WIM ທີ່ສ້າງຂຶ້ນດ້ວຍ wimlib-imagex ຈັບ, ໃນຂະນະທີ່ໄຟລ໌ WIM ໄດ້ຖືກປັບປຸງ
ກັບ wimlib-imagex ເພີ່ມເຕີມ ຈະຖືກຂຽນດ້ວຍຕາຕະລາງຄວາມຊື່ສັດຖ້າແລະພຽງແຕ່ຖ້າຫນຶ່ງ
ມີຢູ່ກ່ອນ.

--ບີບອັດ=TYPE[:LEVEL]
ລະບຸຮູບແບບການບີບອັດສໍາລັບໄຟລ໌ WIM ໃໝ່. TYPE ອາດຈະເປັນ "ບໍ່ມີ", "XPRESS"
(alias: "ໄວ"), "LZX" (alias: "ສູງສຸດ"), ຫຼື "LZMS" (alias: "ການຟື້ນຕົວ"). TYPE is
ຈັບຄູ່ case-insensitively. ຄ່າເລີ່ມຕົ້ນແມ່ນ "LZX".

ທ່ານຍັງສາມາດລະບຸການບີບອັດຈໍານວນເຕັມໄດ້ LEVEL. ລະດັບການບີບອັດ
ກໍານົດວິທີການບີບອັດແຂງສໍາລັບການບີບອັດທີ່ກໍານົດໄວ້ TYPE ຈະ
ເຮັດວຽກເພື່ອບີບອັດຂໍ້ມູນ. ຄ່າໄດ້ຖືກປັບຂະຫນາດເພື່ອໃຫ້ 20 ແມ່ນການບີບອັດໄວ,
50 ແມ່ນການບີບອັດຂະຫນາດກາງ, ແລະ 100 ແມ່ນການບີບອັດສູງ. ຢ່າງໃດກໍຕາມ, ທ່ານສາມາດເລືອກອັນໃດກໍໄດ້
ມູນຄ່າ, ແລະບໍ່ພຽງແຕ່ຄຸນຄ່າສະເພາະເຫຼົ່ານີ້. ຄ່າເລີ່ມຕົ້ນແມ່ນ 50.

ຕົວເລືອກນີ້ມີຜົນກະທົບພຽງແຕ່ປະເພດການບີບອັດທີ່ໃຊ້ໃນຊັບພະຍາກອນ WIM ທີ່ບໍ່ແຂງ. ຖ້າ
ທ່ານກໍາລັງສ້າງ WIM ແຂງ (ການນໍາໃຊ້ --ແຂງ ທາງເລືອກ), ຫຼັງຈາກນັ້ນທ່ານອາດຈະຕ້ອງການ
--solid-compress ແທນທີ່ຈະເປັນ.

ຈົ່ງລະວັງຖ້າທ່ານເລືອກການບີບອັດ LZMS. ມັນບໍ່ເຂົ້າກັນໄດ້ກັບ wimlib ກ່ອນ
v1.6.0, WIMGAPI ກ່ອນ Windows 8, DISM ກ່ອນ Windows 8.1, ແລະ 7-Zip ກ່ອນ v15.12.

ໃຫ້ສັງເກດວ່າການເລືອກການບີບອັດ LZMS ບໍ່ໄດ້ຫມາຍເຖິງຮູບແບບແຂງໂດຍອັດຕະໂນມັດ
ການບີບອັດ, ຄືກັບ DISM. ໃຊ້ --ແຂງ ຖ້າທ່ານຕ້ອງການສ້າງ WIM ແຂງ,
ຫຼື "ໄຟລ໌ ESD".

--chunk-size=ຫລືຂະຫຍາຍໂຕ
ກໍານົດຂະຫນາດ chunk compression ເປັນ ຫລືຂະຫຍາຍໂຕ ໄບຕ໌. ຂະໜາດການບີບອັດທີ່ໃຫຍ່ກວ່າ
ຜົນໄດ້ຮັບໃນອັດຕາສ່ວນການບີບອັດທີ່ດີກວ່າ. wimlib ສະຫນັບສະຫນູນຂະຫນາດ chunk ທີ່ແຕກຕ່າງກັນ
ຂຶ້ນກັບປະເພດຂອງການບີບອັດ:

· 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

ທ່ານສາມາດສະຫນອງຕົວເລກເຕັມ (ຕົວຢ່າງ: 32768), ຫຼືທ່ານສາມາດນໍາໃຊ້ຫນຶ່ງຂອງ K, M, ຫຼື G.
ຄຳຕໍ່ທ້າຍ. KiB, MiB, ແລະ GiB ຍັງໄດ້ຮັບການຍອມຮັບ.

ຕົວເລືອກນີ້ມີຜົນກະທົບພຽງແຕ່ຂະຫນາດ chunk ທີ່ໃຊ້ໃນຊັບພະຍາກອນ WIM ທີ່ບໍ່ແມ່ນແຂງ. ຖ້າ​ຫາກ​ວ່າ​ທ່ານ
ການສ້າງ WIM ແຂງ (ການນໍາໃຊ້ --ແຂງ ທາງເລືອກ), ຫຼັງຈາກນັ້ນທ່ານອາດຈະຕ້ອງການ --ແຂງ-
ຂະ​ຫນາດ chunk​ ແທນທີ່ຈະເປັນ.

ໃຊ້ຕົວເລືອກນີ້ຢ່າງລະມັດລະວັງຖ້າຄວາມເຂົ້າກັນໄດ້ກັບການປະຕິບັດຂອງ Microsoft
ທີ່ຕ້ອງການ, ເນື່ອງຈາກວ່າການປະຕິບັດຂອງເຂົາເຈົ້າມີການສະຫນັບສະຫນູນຈໍາກັດສໍາລັບຂະຫນາດ chunk ທີ່ບໍ່ແມ່ນມາດຕະຖານ.

--ແຂງ
ສ້າງໄຟລ໌ WIM "ແຂງ" ທີ່ບີບອັດໄຟລ໌ຮ່ວມກັນແທນທີ່ຈະເປັນເອກະລາດ.
ນີ້ສົ່ງຜົນໃຫ້ອັດຕາສ່ວນການບີບອັດທີ່ດີກວ່າ, ແຕ່ມັນມາໃນລາຄາ
ຂອງການຊື້ຂາຍຕ່າງໆ, ລວມທັງ: ການບີບອັດຊ້າທີ່ມີການນໍາໃຊ້ຫນ່ວຍຄວາມຈໍາສູງຫຼາຍ; ຊ້າ
ການເຂົ້າເຖິງແບບສຸ່ມກັບໄຟລ໌ WIM ຜົນໄດ້ຮັບ; ແລະຄວາມເຂົ້າກັນໄດ້ຫຼຸດລົງ.

ຄວາມເຂົ້າກັນໄດ້ທີ່ສະຫລາດ, ຮຸ່ນທໍາອິດຂອງ WIMGAPI ຂອງ Microsoft ເພື່ອສະຫນັບສະຫນູນ WIM ແຂງ
ໄຟລ໌ໄດ້ຖືກປ່ອຍອອກມາດ້ວຍ Windows 8, ແລະຮຸ່ນທໍາອິດຂອງ DISM ທີ່ຈະເຮັດແນວນັ້ນແມ່ນ
ປ່ອຍອອກມາເມື່ອກັບ Windows 8.1.

ຖ້າທ່ານຕ້ອງການສ້າງ "ໄຟລ໌ ESD", ຫຼັງຈາກນັ້ນໃຫ້ໃຊ້ທາງເລືອກນີ້. An (unencrypted) "ESD
file" ເປັນໄຟລ໌ WIM ແຂງ.

ໂດຍຄ່າເລີ່ມຕົ້ນ, ຕົວເລືອກນີ້ມີຜົນກະທົບທຽບເທົ່າກັບທາງເລືອກຂອງ DISM
/ ບີບອັດ: ການຟື້ນຕົວ. ທາງເລືອກສໍາລັບ wimlib-imagex ແມ່ນແຕກຕ່າງກັນຍ້ອນວ່າພວກເຂົາພະຍາຍາມ
ບໍ່ໃຫ້ conflate ປະເພດການບີບອັດ (ເຊັ່ນ: LZX ຫຼື LZMS) ດ້ວຍການບີບອັດແບບແຂງ,
ເນື່ອງຈາກວ່າເຫຼົ່ານີ້ແມ່ນສອງສິ່ງທີ່ແຕກຕ່າງກັນ.

--solid-chunk-size=ຫລືຂະຫຍາຍໂຕ
ຄື --chunk-size, ແຕ່ກໍານົດຂະຫນາດ chunk ທີ່ໃຊ້ໃນຊັບພະຍາກອນແຂງ. ຄ່າເລີ່ມຕົ້ນ,
ສົມມຸດວ່າການບີບອັດ LZMS, ແມ່ນ 64MiB (67108864); ອັນນີ້ຕ້ອງການຄວາມຈຳປະມານ 640MiB
ຕໍ່ກະທູ້. ຕົວເລືອກນີ້ມີຜົນກະທົບພຽງແຕ່ເມື່ອ --ແຂງ ຍັງ​ໄດ້​ລະ​ບຸ​ໄວ້​. ຫມາຍ​ເຫດ​:
ການຈັດຕັ້ງປະຕິບັດຂອງ Microsoft ບໍ່ເຂົ້າກັນໄດ້ກັບ LZMS chunk ຂະໜາດໃຫຍ່ກວ່າ
64MiB.

--solid-compress=TYPE[:LEVEL]
ຄື --ບີບອັດ, ແຕ່ກໍານົດປະເພດການບີບອັດທີ່ໃຊ້ໃນຊັບພະຍາກອນແຂງ. ຄ່າເລີ່ມຕົ້ນ
ແມ່ນການບີບອັດ LZMS. ຕົວເລືອກນີ້ມີຜົນກະທົບພຽງແຕ່ເມື່ອ --ແຂງ ຍັງ​ໄດ້​ລະ​ບຸ​ໄວ້​.

-- ກະທູ້=NUM_THREADS
ຈໍານວນກະທູ້ທີ່ຈະໃຊ້ສໍາລັບການບີບອັດຂໍ້ມູນ. ຄ່າເລີ່ມຕົ້ນ: ກວດຫາອັດຕະໂນມັດ (ຈໍານວນ
CPU ທີ່​ມີ​ຢູ່​)​.

-- ສ້າງ​ໃຫມ່​
ສໍາລັບການ wimlib-imagex ເພີ່ມເຕີມ: ສ້າງ WIM ທັງໝົດຄືນໃໝ່ແທນທີ່ຈະຕື່ມຂໍ້ມູນໃໝ່
ໃນຕອນທ້າຍຂອງມັນ. ການສ້າງ WIM ຄືນໃໝ່ແມ່ນຊ້າກວ່າ, ແຕ່ຈະປະຫຍັດພື້ນທີ່ໜ້ອຍໜຶ່ງ
ຖ້າບໍ່ດັ່ງນັ້ນຈະຖືກປະໄວ້ເປັນຂຸມໃນ WIM. ຍັງເບິ່ງ wimlib-imagex
ເພີ່ມປະສິດທິ(1).

--ທຸງ=EDITIONID
ລະບຸສະຕຣິງທີ່ຈະໃຊ້ໃນ ອົງປະກອບຂອງຂໍ້ມູນ XML ສໍາລັບຮູບພາບໃຫມ່.

--ຮູບ-ຊັບສິນ NAME=ມູນຄ່າ
ລະບຸຄຸນສົມບັດຕໍ່ຮູບທີ່ຕ້ອງການເພື່ອກຳນົດໄວ້ໃນເອກະສານ XML ຂອງໄຟລ໌ WIM.
ມູນຄ່າ ແມ່ນສະຕຣິງທີ່ຈະຕັ້ງເປັນຄ່າຄຸນສົມບັດ. NAME ແມ່ນ​ຊື່​ຂອງ​ຮູບ​ພາບ​
ຊັບສິນ, ຕົວຢ່າງ "NAME", "DESCRIPTION", ຫຼື "TOTALBYTES". ຊື່ສາມາດບັນຈຸ
forward slashes ເພື່ອຊີ້ບອກອົງປະກອບ XML ທີ່ຕິດກັນ; ຍົກ​ຕົວ​ຢ່າງ,
"WINDOWS/VERSION/BUILD" ຊີ້ບອກອົງປະກອບ BUILD ທີ່ຕິດຢູ່ພາຍໃນ VERSION
ອົງປະກອບທີ່ຕັ້ງຢູ່ໃນອົງປະກອບ WINDOWS. ຕົວເລກວົງເລັບສາມາດຖືກນໍາໃຊ້ເພື່ອ
ຊີ້ບອກໜຶ່ງໃນຫຼາຍອົງປະກອບທີ່ມີຊື່ຄືກັນ; ຍົກ​ຕົວ​ຢ່າງ,
"WINDOWS/LANGUAGES/LANGUAGE[2]" ຊີ້ບອກອົງປະກອບ "LANGUAGE" ທີສອງທີ່ຊ້ອນກັນ
ພາຍໃນອົງປະກອບ "WINDOWS/LANGUAGES". ເມື່ອເພີ່ມບັນຊີລາຍຊື່ຂອງອົງປະກອບດ້ວຍວິທີນີ້,
ພວກມັນຈະຕ້ອງຖືກລະບຸໄວ້ໃນລໍາດັບຕາມລໍາດັບ. ໃຫ້ສັງເກດວ່າຊື່ອົງປະກອບແມ່ນກໍລະນີ -
ອ່ອນໄຫວ. ຕົວເລືອກນີ້ອາດຈະຖືກລະບຸຫຼາຍຄັ້ງ.

--ການອ້າງອິງ
(ລະບົບທີ່ຄ້າຍຄື UNIX ເທົ່ານັ້ນ) ປະຕິບັດຕາມການເຊື່ອມຕໍ່ສັນຍາລັກ ແລະເກັບໄຟລ໌ທີ່ເຂົາເຈົ້າຊີ້ໄປຫາ,
ແທນທີ່ຈະເກັບການເຊື່ອມຕໍ່ດ້ວຍຕົນເອງ.

--config=ເອກະສານ
ລະບຸໄຟລ໌ການຕັ້ງຄ່າ (UTF-8 ຫຼື UTF-16LE ເຂົ້າລະຫັດ; ASCII ທໍາມະດາຍັງໃຊ້ໄດ້)
ສໍາລັບການຈັບພາບໃຫມ່. ໄຟລ໌ການຕັ້ງຄ່າກໍານົດໄຟລ໌ທີ່ຈະເປັນ
ໄດ້ຮັບການປິ່ນປົວພິເສດໃນລະຫວ່າງການຈັບພາບ.

ຮູບແບບຂອງໄຟລ໌ການຕັ້ງຄ່າແມ່ນແບບ INI; ນັ້ນແມ່ນ, ມັນຖືກຈັດໃສ່ໃນ
ພາກສ່ວນທີ່ມີວົງເລັບ. ໃນປັດຈຸບັນ, ພາກສ່ວນຕໍ່ໄປນີ້ໄດ້ຖືກຮັບຮູ້:

· [ExclusionList] --- ມີບັນຊີລາຍຊື່ຂອງ globs ເສັ້ນທາງທີ່ຈະຍົກເວັ້ນຈາກການ capture. ຖ້າ
ໄດເລກະທໍລີຖືກຈັບຄູ່, ທັງໄດເລກະທໍລີແລະເນື້ອຫາຂອງມັນຖືກຍົກເວັ້ນ.

· [ExclusionException] --- ມີບັນຊີລາຍຊື່ຂອງ globs ເສັ້ນທາງທີ່ຈະລວມຢູ່ໃນ
capture, ເຖິງແມ່ນວ່າໃນເວລາທີ່ໄຟລ໌ຫຼືໄດເລກະທໍລີຍັງກົງກັບ glob ໃນ [ExclusionList].

· [PrepopulateList] --- ອັນນີ້ບໍ່ມີຜົນກະທົບຕໍ່ການຈັບພາບ, ແຕ່ຖ້າໃຊ້ຮູບພາບ
ຕໍ່ມາ --wimboot, ເຫຼົ່ານີ້ແມ່ນ globs ຂອງໄຟລ໌ທີ່ຈະໄດ້ຮັບການສະກັດເປັນປົກກະຕິ,
ບໍ່ແມ່ນ "ໄຟລ໌ຕົວຊີ້". ຖ້າໄດເລກະທໍລີຖືກຈັບຄູ່, ໄຟລ໌ທັງຫມົດແລະ
ໄດເລກະທໍລີຍ່ອຍຍັງຖືກຈັບຄູ່ແບບ recursively.

globs ເສັ້ນທາງອາດມີ '*' ແລະ '?' ຕົວອັກສອນ meta. globs ພີ່ນ້ອງ (ຕົວຢ່າງ
*.mp3) ກົງກັບຊື່ໄຟລ໌ໃນໄດເລກະທໍລີໃດນຶ່ງ. globs ຢ່າງແທ້ຈິງ (ຕົວຢ່າງ /dir/file),
ຖືກປະຕິບັດເປັນເສັ້ນທາງເລີ່ມຕົ້ນຢູ່ໃນໄດເລກະທໍລີຕົ້ນຕໍທີ່ຖືກຈັບ, ຫຼືຮາກຂອງ
ປະລິມານ NTFS ສໍາລັບໂຫມດການຈັບປະລິມານ NTFS. ຫ້າມໃຊ້ຕົວອັກສອນຂັບໃນ
ເສັ້ນທາງ; ເຂົາເຈົ້າຈະຖືກລະເລີຍ. ຕົວແຍກເສັ້ນທາງອາດຈະເປັນການເລື່ອນໄປຂ້າງໜ້າ ຫຼື
ທັບຫຼັງ.

ແຖວທີ່ເລີ່ມຕົ້ນດ້ວຍ '#' ຫຼື ';' ຕົວອັກສອນຖືກປະຕິບັດເປັນຄໍາເຫັນແລະຖືກລະເລີຍ.
Globs ທີ່ມີຊ່ອງຫວ່າງຢູ່ໃນພວກມັນບໍ່ຈໍາເປັນຕ້ອງຖືກອ້າງອີງ; ຢ່າງໃດກໍຕາມ, ຖ້າພວກເຂົາເປັນ, ທັງສອງສອງເທົ່າ
ແລະຄໍາເວົ້າດຽວຖືກຍອມຮັບ.

ຖ້າຕົວເລືອກນີ້ບໍ່ໄດ້ຖືກລະບຸ, ໄຟລ໌ການຕັ້ງຄ່າເລີ່ມຕົ້ນຕໍ່ໄປນີ້ຖືກໃຊ້:

[ລາຍການຍົກເວັ້ນ]
\$ntfs.log
\hiberfil.sys
\pagefile.sys
\swapfile.sys
\ ຂໍ້ມູນປະລິມານລະບົບ
\ລີໄຊເຄີນ
\Windows\CSC

ຢ່າງໃດກໍຕາມ, ພຶດຕິກໍາພິເສດໃຊ້ຖ້າ --wimboot ຍັງ​ໄດ້​ລະ​ບຸ​ໄວ້​. ໂດຍຄ່າເລີ່ມຕົ້ນ, ກັບ
--wimboot ລະບຸໄວ້, ໄຟລ໌ Windows/System32/WimBootCompress.ini ໃນໄດເລກະທໍລີ
ຖືກຈັບຈະຖືກໃຊ້ເປັນໄຟລ໌ການຕັ້ງຄ່າ. ຢ່າງໃດກໍຕາມ, ນີ້ສາມາດເປັນ
overridden ການ​ນໍາ​ໃຊ້​ --config; ແລະນີ້ຍັງເຮັດໃຫ້ໄຟລ໌ການຕັ້ງຄ່າທີ່ກໍານົດໄວ້
ຖືກບັນທຶກໄວ້ໃນຮູບ WIM ເປັນ Windows/System32/WimBootCompress.ini, overriding ໃດ.
ທີ່ອາດຈະມີຢູ່ໃນລະບົບໄຟລ໌.

--unix-data
(ລະບົບທີ່ຄ້າຍຄືກັບ UNIX ເທົ່ານັ້ນ) ເກັບຮັກສາເຈົ້າຂອງ UNIX, ກຸ່ມ, ໂໝດ ແລະ ID ອຸປະກອນ (ອັນສຳຄັນ ແລະ
ຈໍານວນເລັກນ້ອຍ) ຂອງແຕ່ລະໄຟລ໌ທີ່ຖືກຈັບ. ໃນຖານະເປັນຂອງ wimlib v1.7.0, ທ່ານສາມາດສໍາຮອງຂໍ້ມູນແລະ
ຟື້ນຟູບໍ່ພຽງແຕ່ຂໍ້ມູນການອະນຸຍາດໄຟລ໌ UNIX ມາດຕະຖານ, ແຕ່ຍັງມີລັກສະນະ
nodes ອຸປະກອນ, ບລັອກອຸປະກອນ, ທໍ່ທີ່ມີຊື່ (FIFOs), ແລະຊັອກເກັດໂດເມນ UNIX.

wimlib ເກັບຮັກສາຂໍ້ມູນ UNIX ໂດຍການເພີ່ມລາຍການເມຕາເດຕາທີ່ຖືກແທັກພິເສດໃສ່ແຕ່ລະໄດເລກະທໍລີ
ແຕ່ລະໄຟລ໌ທີ່ມີຂໍ້ມູນນີ້. ຂໍ້ມູນເພີ່ມເຕີມນີ້ແມ່ນ
ຖືກລະເລີຍໂດຍການຈັດຕັ້ງປະຕິບັດ Microsoft. ໝາຍເຫດ: ຂໍ້ມູນ UNIX ເກັບໄວ້ໂດຍ wimlib ກ່ອນ
v1.7.0 ໃຊ້ຮູບແບບອື່ນທີ່ບໍ່ຮອງຮັບອີກຕໍ່ໄປ. ຖ້າທ່ານມີ WIM ເກົ່າ
ໄຟລ໌ທີ່ມີຂໍ້ມູນ UNIX, ນຳໃຊ້ພວກມັນດ້ວຍ v1.6.2 ແລະເກັບຄືນພວກມັນດ້ວຍ v1.7.0 ຫຼື
ຕໍ່ມາ.

--no-acls
ຢ່າຈັບຕົວອະທິບາຍຄວາມປອດໄພຂອງໄຟລ໌.

--strict-acls
ລົ້ມເຫລວທັນທີຖ້າຕົວອະທິບາຍຄວາມປອດໄພອັນເຕັມທີ່ຂອງໄຟລ໌ໃດນຶ່ງບໍ່ສາມາດອ່ານໄດ້. ສຸດ
Windows, ພຶດຕິກຳເລີ່ມຕົ້ນທີ່ບໍ່ມີທາງເລືອກນີ້ແມ່ນເພື່ອທົດລອງຍົກເລີກ SACL ທຳອິດ
ຈາກຕົວອະທິບາຍຄວາມປອດໄພ, ຈາກນັ້ນພະຍາຍາມລະເວັ້ນຕົວອະທິບາຍຄວາມປອດໄພທັງໝົດ.
ຈຸດປະສົງຂອງການນີ້ແມ່ນເພື່ອເກັບກໍາຂໍ້ມູນຫຼາຍເທົ່າທີ່ເປັນໄປໄດ້ໂດຍບໍ່ຈໍາເປັນຕ້ອງສະເຫມີ
ສິດທິພິເສດຂອງຜູ້ບໍລິຫານ. ຢ່າງໃດກໍຕາມ, ຖ້າທ່ານຕ້ອງການໃຫ້ຄໍາອະທິບາຍຄວາມປອດໄພທັງຫມົດ
captured ແທ້, ທ່ານອາດຈະຕ້ອງການທີ່ຈະສະຫນອງທາງເລືອກນີ້, ເຖິງແມ່ນວ່າ Administrator
ຄວນມີການອະນຸຍາດໃຫ້ອ່ານທຸກຢ່າງ.

--rpfix, --norpfix
ກໍານົດວ່າຈະແກ້ໄຂເປົ້າຫມາຍຂອງການເຊື່ອມຕໍ່ສັນຍາລັກຢ່າງແທ້ຈິງ (ຈຸດ reparse ໃນ Windows
ຄຳສັບ) ຫຼືບໍ່. ເມື່ອເປີດໃຊ້ງານ (--rpfix), ການເຊື່ອມຕໍ່ສັນຍາລັກຢ່າງແທ້ຈິງຈຸດນັ້ນ
ພາຍໃນໄດເລກະທໍລີຕົ້ນໄມ້ຖືກຈັບຈະຖືກປັບໃຫ້ສົມທຽບຢ່າງແທ້ຈິງ
ຮາກຂອງຕົ້ນໄມ້ໄດເລກະທໍລີຖືກຈັບ. ເມື່ອປິດການໃຊ້ງານ (--norpfix), ຢ່າງແທ້ຈິງ
ການເຊື່ອມຕໍ່ສັນຍາລັກຈະຖືກຈັບຢ່າງແນ່ນອນ.

ພຶດຕິກໍາເລີ່ມຕົ້ນສໍາລັບ wimlib-imagex ຈັບ ເທົ່າກັບ --rpfix. ໄດ້
ພຶດຕິກໍາເລີ່ມຕົ້ນສໍາລັບ wimlib-imagex ເພີ່ມເຕີມ ຈະ​ເປັນ --rpfix ຖ້າ​ຫາກ​ວ່າ reparse fixups ຈຸດ​
ໄດ້​ເຮັດ​ໃນ​ເມື່ອ​ກ່ອນ​ WIMFILE, ຖ້າບໍ່ດັ່ງນັ້ນ --norpfix.

ໃນກໍລະນີຂອງການຈັບພາບຫຼາຍແຫຼ່ງ, (--source-list ລະບຸ), ຜ່ານ --norpfix
ແມ່ນແນະນໍາ. ຖ້າບໍ່ດັ່ງນັ້ນ, ການແກ້ໄຂຈຸດ reparse ຈະຖືກປິດໃຊ້ງານຢູ່ໃນທຸກ capture
ແຫຼ່ງທີ່ຕັ້ງໄວ້ສໍາລັບສະຖານທີ່ທີ່ບໍ່ແມ່ນຮາກຢູ່ໃນຮູບພາບ WIM, ໃນຂະນະທີ່ແຫຼ່ງຈັບພາບ
destined ສໍາລັບຮາກ WIM ຈະໄດ້ຮັບພຶດຕິກໍາເລີ່ມຕົ້ນຈາກວັກທີ່ຜ່ານມາ.

--source-list
wimlib-imagex ຈັບ ແລະ wimlib-imagex ເພີ່ມເຕີມ ສະຫນັບສະຫນູນການສ້າງຮູບພາບ WIM ຈາກ
ໄຟລ໌ ຫຼືໄດເລກະທໍລີແຍກຕ່າງຫາກຫຼາຍອັນ. ເມື່ອ​ໃດ​ --source-list ຖືກກໍານົດ, ໄດ້ ແຫຼ່ງຂໍ້ມູນ
argument ລະບຸຊື່ຂອງໄຟລ໌ຂໍ້ຄວາມ, ແຕ່ລະແຖວແມ່ນ 1 ຫຼື 2
ຊ່ອງຫວ່າງທີ່ແຍກເສັ້ນທາງໄຟລ໌. ເສັ້ນທາງໄຟລ໌ທໍາອິດ, ແຫຼ່ງ, ກໍານົດ
ເສັ້ນທາງໄປຫາໄຟລ໌ຫຼືໄດເລກະທໍລີເພື່ອບັນທຶກເຂົ້າໄປໃນຮູບພາບ WIM. ມັນອາດຈະເປັນ
ຢ່າງແທ້ຈິງຫຼືກ່ຽວຂ້ອງກັບໄດເລກະທໍລີທີ່ເຮັດວຽກໃນປະຈຸບັນ. ເສັ້ນທາງໄຟລ໌ທີສອງ, ຖ້າ
ສະຫນອງໃຫ້, ແມ່ນເປົ້າຫມາຍແລະກໍານົດເສັ້ນທາງໃນຮູບພາບ WIM ທີ່ໄຟລ໌ນີ້ຫຼື
ໄດເລກະທໍລີຈະຖືກບັນທຶກເປັນ. ການຕີນຳໜ້າ ແລະຕາມຫຼັງໃນເປົ້າໝາຍແມ່ນຖືກລະເລີຍ,
ຍົກ​ເວັ້ນ​ຖ້າ​ຫາກ​ວ່າ​ມັນ​ປະ​ກອບ​ດ້ວຍ slashes ທັງ​ຫມົດ (eg "/"), ເຊິ່ງ​ຊີ້​ໃຫ້​ເຫັນ​ວ່າ​
ໄດເລກະທໍລີແມ່ນເພື່ອກາຍເປັນຮາກຂອງຮູບພາບ WIM. ຖ້າຖືກລະເວັ້ນ, ສະຕຣິງເປົ້າໝາຍ
ເລີ່ມຕົ້ນຄືກັນກັບສະຕຣິງຕົ້ນສະບັບ.

ໄຟລ໌ລາຍຊື່ແຫຼ່ງຕົວຢ່າງມີດັ່ງນີ້:

# ເຮັດຮູບ WIM ຈາກໄດເລກະທໍລີ 'winpe'
winpe /

# ສົ່ງລາຍການ 'overlay' ໄປ '/overlay' ໃນຮູບ WIM
overlay / overlay

# ວາງໃສ່ໄດເລກະທໍລີແຍກຕ່າງຫາກໂດຍກົງໃສ່ຮາກຂອງຮູບ WIM.
/data/ stuff /

ໄດເລກະທໍລີຍ່ອຍໃນ WIM ຖືກສ້າງຂື້ນຕາມຄວາມຕ້ອງການ. ໄດເລກະທໍລີແຫຼ່ງຫຼາຍອາດຈະ
ແບ່ງປັນເປົ້າຫມາຍດຽວກັນ, ເຊິ່ງຫມາຍເຖິງການຊ້ອນກັນ. ໃນກໍລະນີທີ່ຜົນໄດ້ຮັບນີ້ ກ
ໄຟລ໌ nondirectory ຖືກເພີ່ມໃສ່ຮູບພາບ WIM ຫຼາຍຄັ້ງ, ສະບັບສຸດທ້າຍ (ເປັນ
ລະບຸໄວ້ໃນໄຟລ໌ລາຍຊື່ແຫຼ່ງ) overrides ເວີຊັນກ່ອນໜ້ານີ້.

ເສັ້ນທາງໄຟລ໌ທີ່ມີຊ່ອງຫວ່າງອາດຈະຖືກອ້າງອີງດ້ວຍວົງຢືມດຽວ ຫຼືສອງເທົ່າ
ວົງຢືມ. ວົງຢືມອາດຈະບໍ່ຫລົບຫນີ.

ເສັ້ນທີ່ປະກອບດ້ວຍຊ່ອງຫວ່າງເທົ່ານັ້ນ ແລະເສັ້ນທີ່ຂຶ້ນຕົ້ນດ້ວຍ '#' ນຳໜ້າດ້ວຍ
ຊ່ອງຫວ່າງທາງເລືອກແມ່ນຖືກລະເລີຍ.

ເປັນກໍລະນີພິເສດ, ຖ້າ ແຫຼ່ງຂໍ້ມູນ ແມ່ນ "-", ລາຍຊື່ແຫຼ່ງແມ່ນອ່ານຈາກວັດສະດຸປ້ອນມາດຕະຖານ
ແທນທີ່ຈະເປັນໄຟລ໌ພາຍນອກ.

ໂໝດການຈັບປະລິມານ NTFS ໃນລະບົບຄ້າຍ UNIX ບໍ່ສາມາດໃຊ້ກັບ --source-list,
ເນື່ອງຈາກວ່າພຽງແຕ່ການຈັບປະລິມານ NTFS ເຕັມແມ່ນສະຫນັບສະຫນູນ.

--pipable
ສ້າງ WIM "pipable", ເຊິ່ງສາມາດນໍາໃຊ້ໄດ້ຢ່າງສົມບູນຕາມລໍາດັບ, ລວມທັງຈາກ a
ທໍ່. ຮູບພາບໃນ WIM ຜົນໄດ້ຮັບສາມາດຖືກນໍາໃຊ້ກັບ wimlib-imagex ນໍາໃຊ້, ທັງ
ໂດຍປົກກະຕິໂດຍການລະບຸຊື່ໄຟລ໌ WIM, ຫຼືດ້ວຍ wimlib-imagex ນໍາໃຊ້ - ອ່ານ
WIM ຈາກການປ້ອນຂໍ້ມູນມາດຕະຖານ. ເບິ່ງ wimlib-imagex ນໍາໃຊ້(1) ສໍາລັບລາຍລະອຽດເພີ່ມເຕີມ.

ສໍາລັບການດໍາເນີນງານເພີ່ມເຕີມ, ທາງເລືອກນີ້ຈະສົ່ງຜົນໃຫ້ WIM ກໍ່ສ້າງຄືນໃຫມ່ຢ່າງເຕັມທີ່
ມັນ pipable. ສໍາ​ລັບ​ການ​ດໍາ​ເນີນ​ງານ​ການ​ຈັບ​ພາບ​, WIM ທີ່​ຈັບ​ໄດ້​ຖືກ​ສ້າງ​ຕັ້ງ​ຂຶ້ນ​ພຽງ​ແຕ່​ເປັນ pipable​.
ຈົ່ງລະວັງວ່າ ຍິ່ງເຈົ້າເພີ່ມຮູບໃສ່ WIM ທີ່ສາມາດສົ່ງໄດ້ຫຼາຍເທົ່າໃດ, ທໍ່ນັ້ນມີປະສິດທິພາບໜ້ອຍລົງ
ຈະເປັນ, ເນື່ອງຈາກວ່າຂໍ້ມູນທີ່ບໍ່ຈໍາເປັນຫຼາຍຈະຖືກສົ່ງຜ່ານທໍ່.

ເມື່ອ wimlib ສ້າງ WIM pipable, ມັນຈັດແຈງອົງປະກອບຂອງ ໃໝ່ ຢ່າງລະມັດລະວັງ
WIM ເພື່ອ​ໃຫ້​ພວກ​ເຂົາ​ເຈົ້າ​ສາ​ມາດ​ອ່ານ​ຕາມ​ລໍາ​ດັບ​ແລະ​ຍັງ​ເຮັດ​ໃຫ້​ອື່ນໆ​ຈໍາ​ນວນ​ຫນຶ່ງ​
ການ​ດັດ​ແກ້​. ດັ່ງນັ້ນ, WIMs "pipable" ເຫຼົ່ານີ້ແມ່ນ ບໍ່ ເຂົ້າກັນໄດ້ ກັບ
Microsoft ຂອງ ຊອບແວ, ສະນັ້ນຈົ່ງຈື່ໄວ້ວ່າຖ້າທ່ານຈະໃຊ້ພວກມັນ. ຖ້າຕ້ອງການ,
ທ່ານສາມາດໃຊ້ wimlib-imagex ເພີ່ມປະສິດທິ --ບໍ່ທໍ່ ເພື່ອຂຽນຄືນໃຫມ່ pipable WIM ເປັນ
WIM ປົກກະຕິ. (wimlib-imagex ການສົ່ງອອກ ຍັງສະຫນອງຄວາມສາມາດໃນການສົ່ງອອກຮູບພາບ
ຈາກ WIM pipable ເຂົ້າໄປໃນ WIM ທີ່ບໍ່ແມ່ນ pipable, ຫຼືໃນທາງກັບກັນ.)

ສໍາລັບສ່ວນໃຫຍ່, wimlib ດໍາເນີນການກ່ຽວກັບ WIMs pipable ໂປ່ງໃສ. ທ່ານ​ສາ​ມາດ​ປັບ​ປຸງ​ແກ້​ໄຂ​
ເຂົາເຈົ້າ, ເພີ່ມຫຼືລຶບຮູບພາບ, ສົ່ງອອກຮູບພາບ, ແລະແມ້ກະທັ້ງສ້າງ pipable WIMs ແຍກ. ໄດ້
ຂໍ້ເສຍຕົ້ນຕໍແມ່ນວ່າການເພີ່ມເຕີມແມ່ນ (ປະຈຸບັນ) ປະສິດທິພາບຫນ້ອຍ (-- ສ້າງ​ໃຫມ່​ is
ສະ​ເໝີ​ຕົ້ນ​ສະ​ເໝີ​ປາຍ), ແລະ​ພວກ​ມັນ​ບໍ່​ເຂົ້າ​ກັນ​ໄດ້​ກັບ​ຊອບ​ແວ Microsoft.

wimlib-imagex ຈັບ ແລະ wimlib-imagex ເພີ່ມເຕີມ ທັງສອງສາມາດຂຽນ WIM pipable ໂດຍກົງ
ຜົນຜະລິດມາດຕະຖານ; ນີ້​ແມ່ນ​ເຮັດ​ໄດ້​ອັດ​ຕະ​ໂນ​ມັດ​ຖ້າ​ຫາກ​ວ່າ​ WIMFILE ຖືກກໍານົດເປັນ "-". (ໃນ
ກໍ​ລະ​ນີ​ນັ້ນ​, --pipable ຄາດ​ວ່າ​.)

--ບໍ່ທໍ່
ໃຫ້ແນ່ໃຈວ່າ WIM ຜົນໄດ້ຮັບແມ່ນຢູ່ໃນຮູບແບບ WIM ປົກກະຕິ, ທີ່ບໍ່ແມ່ນ pipable. ນີ້​ແມ່ນ
ຄ່າເລີ່ມຕົ້ນສໍາລັບ wimlib-imagex ຈັບ, ຍົກ​ເວັ້ນ​ໃນ​ເວ​ລາ​ທີ່​ການ​ຂຽນ​ກັບ​ຜົນ​ຜະ​ລິດ​ມາດ​ຕະ​ຖານ (WIMFILE
ລະບຸເປັນ "-"), ແລະຍັງສໍາລັບ wimlib-imagex ເພີ່ມເຕີມ, ຍົກ​ເວັ້ນ​ເມື່ອ​ຕໍ່​ທ້າຍ​ກັບ WIM​
ທີ່ເປັນ pipable ແລ້ວ.

--ອັບເດດ-ຂອງ=[WIMFILE:]ຮູບພາບ
ປະ​ກາດ​ວ່າ​ຮູບ​ພາບ​ທີ່​ຖືກ​ຈັບ​ຫຼື​ຕໍ່​ທ້າຍ​ຈາກ​ ແຫຼ່ງຂໍ້ມູນ ສ່ວນຫຼາຍແມ່ນຄືກັນກັບ
ຮູບ​ພາບ​ທີ່​ມີ​ຢູ່​ແລ້ວ​ ຮູບພາບ in WIMFILE, ແຕ່ຖືກຈັບໃນເວລາຕໍ່ມາ, ເປັນໄປໄດ້
ດ້ວຍການດັດແປງບາງຢ່າງໃນເວລາແຊກແຊງ. ນີ້ໄດ້ຖືກອອກແບບເພື່ອນໍາໃຊ້ໃນ
ການສໍາຮອງຂໍ້ມູນທີ່ເພີ່ມຂຶ້ນຂອງລະບົບໄຟລ໌ດຽວກັນຫຼືຕົ້ນໄມ້ໄດເລກະທໍລີ. ຮູບພາບ ສາມາດເປັນ
1-based index ຫຼືຊື່ຂອງຮູບພາບທີ່ມີຢູ່ແລ້ວໃນ WIMFILE. ມັນຍັງສາມາດເປັນທາງລົບ
integer ເພື່ອດັດສະນີກັບຄືນໄປບ່ອນໃນຮູບພາບຕ່າງໆ (ເຊັ່ນ: -1 ຫມາຍຄວາມວ່າຮູບພາບສຸດທ້າຍທີ່ມີຢູ່ແລ້ວ
in WIMFILE).

ເມື່ອທາງເລືອກນີ້ຖືກສະຫນອງໃຫ້, ການຈັບພາບຫຼືສ່ວນທ້າຍຂອງຮູບພາບໃຫມ່ຈະເປັນ
ປັບປຸງໂດຍການບໍ່ອ່ານໄຟລ໌ທີ່ອີງໃສ່ metadata ເຊັ່ນ: timestamps, ປາກົດ
ບໍ່ໄດ້ຮັບການດັດແກ້ນັບຕັ້ງແຕ່ພວກເຂົາຖືກເກັບໄວ້ໃນທີ່ມີຢູ່ແລ້ວ ຮູບພາບ. ຂັດຂວາງ
ການຫມູນໃຊ້ການສະແຕມເວລາ, ທາງເລືອກນີ້ພຽງແຕ່ມີຜົນກະທົບຕໍ່ການປະຕິບັດແລະບໍ່ປ່ຽນແປງ
ຮູບພາບ WIM ຜົນໄດ້ຮັບ.

ດັ່ງທີ່ສະແດງ, syntax ເຕັມສໍາລັບການໂຕ້ຖຽງກັບທາງເລືອກນີ້ແມ່ນເພື່ອລະບຸ WIM
ໄຟລ໌, ຈໍ້າສອງເມັດ, ແລະຮູບພາບ; ຕົວຢ່າງ, "--update-of mywim.wim:1". ຢ່າງໃດກໍຕາມ, ໄດ້
ໄຟລ໌ WIM ແລະຈໍ້າສອງເມັດອາດຈະຖືກລະເວັ້ນ, ໃນກໍລະນີນີ້ໄຟລ໌ WIM ຈະເປັນຄ່າເລີ່ມຕົ້ນ
ໄຟລ໌ WIM ຈະຖືກຕໍ່ທ້າຍເພື່ອດໍາເນີນການຕໍ່ທ້າຍ, ຫຼືໄຟລ໌ WIM ທີ່ເປັນ delta
ກໍາລັງຖືກປະຕິບັດ (ພຽງແຕ່ຖ້າ --delta-ຈາກ ຖືກລະບຸແນ່ນອນຄັ້ງດຽວ) ສໍາລັບການຈັບ
ການປະຕິບັດງານ.

--delta-ຈາກ=WIMFILE
ສໍາລັບການ wimlib-imagex ຈັບ ພຽງແຕ່: ຈັບ WIM ໃຫມ່ເປັນ "delta" ຈາກ WIMFILEທີ່ຢູ່ ທຸກໆຢ່າງ
ກະແສທີ່ປົກກະຕິຈະຕ້ອງຖືກເກັບໄວ້ໃນ WIM ໃໝ່ຈະຖືກລະເວັ້ນຖ້າພວກມັນ
ມີຢູ່ແລ້ວໃນ WIMFILE ທີ່ delta ແມ່ນອີງໃສ່. WIM ໃຫມ່
ຈະຍັງຄົງມີສຳເນົາອັນເຕັມທີ່ຂອງເມຕາເດຕາຂອງຮູບພາບ, ແຕ່ໂດຍທົ່ວໄປແລ້ວນີ້ແມ່ນພຽງແຕ່ a
ສ່ວນນ້ອຍຂອງຂະໜາດທັງໝົດຂອງ WIM.

ທາງເລືອກນີ້ສາມາດຖືກກໍານົດຫຼາຍຄັ້ງ, ໃນກໍລະນີນີ້ຜົນໄດ້ຮັບ delta WIM
ຈະມີສະເພາະສະຕຣີມທີ່ບໍ່ມີຢູ່ໃນ WIM ພື້ນຖານໃດນຶ່ງທີ່ລະບຸໄວ້.

ເພື່ອດໍາເນີນການກ່ຽວກັບຜົນໄດ້ຮັບ delta WIM ໂດຍໃຊ້ຄໍາສັ່ງອື່ນໆເຊັ່ນ: wimlib-imagex
ນໍາໃຊ້, ທ່ານຕ້ອງລະບຸ delta WIM ເປັນໄຟລ໌ WIM ເພື່ອດໍາເນີນການ, ແຕ່ຍັງ
ອ້າງອີງພື້ນຖານ WIM ໂດຍໃຊ້ --ref ທາງເລືອກ. ລະວັງ: ເພື່ອຮັກສາຄວາມເໝາະສົມ
ການເຮັດວຽກຂອງ delta WIM, ທ່ານພຽງແຕ່ສາມາດເພີ່ມ, ບໍ່ລຶບ, ໄຟລ໌ແລະຮູບພາບຕ່າງໆ
ພື້ນຖານ WIM (s) ປະຕິບັດຕາມການຍຶດເອົາ delta ຈາກມັນ.

--delta-ຈາກ ອາດຈະຖືກລວມເຂົ້າກັບ --ອັບເດດ-ຂອງ ເພື່ອ​ເພີ່ມ​ຄວາມ​ໄວ​ຂອງ​ການ​ຈັບ​ໄດ້​
Delta WIM.

ສໍາລັບຕົວຢ່າງ, ພິຈາລະນາການສໍາຮອງຂໍ້ມູນແລະການຟື້ນຟູລໍາດັບຕໍ່ໄປນີ້:

(ສໍາຮອງເບື້ອງຕົ້ນ)

$ wimcapture /some/directory bkup-base.wim

(ບາງມື້ຕໍ່ມາ, ສ້າງການສໍາຮອງຂໍ້ມູນທີສອງເປັນ delta ຈາກທໍາອິດ)

$ wimcapture /some/directory bkup-2013-08-20.dwm \
--update-of bkup-base.wim:-1 --delta-from bkup-base.wim

(ການ​ຟື້ນ​ຟູ​ການ​ສໍາ​ຮອງ​ຂໍ້​ມູນ​ຄັ້ງ​ທີ​ສອງ​)

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

ຢ່າງໃດກໍຕາມ, ໃຫ້ສັງເກດວ່າເປັນທາງເລືອກກັບລໍາດັບຂ້າງເທິງທີ່ໃຊ້ delta WIM,
ການສໍາຮອງຂໍ້ມູນທີສອງສາມາດຖືກຄັດຕິດໃສ່ WIM ເປັນຮູບພາບໃຫມ່ໂດຍໃຊ້
wimlib-imagex ເພີ່ມເຕີມ. Delta WIMs ຄວນຖືກນໍາໃຊ້ພຽງແຕ່ຖ້າມັນຕ້ອງການພື້ນຖານ
ສໍາຮອງຂໍ້ມູນຫຼືຮູບພາບຢູ່ໃນໄຟລ໌ຂະຫນາດໃຫຍ່ແຍກຕ່າງຫາກທີ່ບໍ່ຄ່ອຍຖືກດັດແກ້.

ຫມາຍເຫດ: ບໍ່ເຫມືອນກັບ "pipable" WIMs (ສ້າງດ້ວຍ --pipable option), "delta" WIMs
(ສ້າງ​ດ້ວຍ --delta-ຈາກ option) ແມ່ນເຂົ້າກັນໄດ້ກັບຊອບແວຂອງ Microsoft.
ຕົວຢ່າງ, ທ່ານສາມາດນໍາໃຊ້ທາງເລືອກ /ref ຂອງ ImageX ເພື່ອອ້າງອີງ WIM ພື້ນຖານ.
ຄ້າຍຄືກັນກັບຂ້າງເທິງ.

ຫມາຍເຫດເພີ່ມເຕີມ: wimlib-imagex ແມ່ນໂດຍທົ່ວໄປພຽງພໍທີ່ເຈົ້າສາມາດລວມເຂົ້າກັນໄດ້
--pipable ແລະ --delta-ຈາກ ເພື່ອສ້າງ pipable delta WIMs. ໃນກໍລະນີດັ່ງກ່າວ, ພື້ນຖານ
WIM ຈະຕ້ອງຖືກຈັບເປັນ pipable ເຊັ່ນດຽວກັນກັບ delta WIM, ແລະໃນເວລາທີ່ສະຫມັກຂໍເອົາ
ຮູບພາບ, WIM ພື້ນຖານຕ້ອງຖືກສົ່ງຜ່ານທໍ່ຫຼັງຈາກ delta WIM.

--wimboot
ໝາຍຮູບເປັນ WIMBoot-compatible. ເບິ່ງເອກະສານຂອງ Microsoft ສໍາລັບຂໍ້ມູນເພີ່ມເຕີມ
ຂໍ້ມູນກ່ຽວກັບ WIMBoot. ທາງເລືອກນີ້ຈະ, ໂດຍຄ່າເລີ່ມຕົ້ນ, ກໍານົດປະເພດການບີບອັດ
ກັບ XPRESS ແລະຂະຫນາດ chunk ເປັນ 4096 bytes; ເຫຼົ່ານີ້ສາມາດ, ຢ່າງໃດກໍຕາມ, ຍັງສາມາດ overridden
ໂດຍຜ່ານການ --ບີບອັດ ແລະ --chunk-size ຕົວກໍານົດການ, ຕາມລໍາດັບ. ນອກຈາກນັ້ນ, ນີ້
ທາງເລືອກຈະ, ໂດຍຄ່າເລີ່ມຕົ້ນ, ຕັ້ງໄຟລ໌ການຕັ້ງຄ່າເປັນ
ແຫຼ່ງຂໍ້ມູນ\Windows\System32\WimBootCompress.ini ຖ້າມີ ແລະສາມາດເຂົ້າເຖິງໄດ້; ຢ່າງໃດກໍຕາມ, ນີ້
ຍັງອາດຈະຖືກ overridden ຜ່ານ --config ພາລາມິເຕີ.

--ບໍ່ປອດໄພ-ກະທັດຮັດ
ເບິ່ງເອກະສານສໍາລັບທາງເລືອກນີ້ໃນ wimlib-imagex-optimize (1).

--ພາບຖ່າຍ
ທົດລອງ: ສ້າງພາບຖ່າຍລະບົບໄຟລ໌ຊົ່ວຄາວຂອງໄດເລກະທໍລີແຫຼ່ງ ແລະ
ຈັບ​ໄຟລ​໌​ຈາກ​ມັນ​. ໃນ​ປັດ​ຈຸ​ບັນ​, ທາງ​ເລືອກ​ນີ້​ແມ່ນ​ສະ​ຫນັບ​ສະ​ຫນູນ​ພຽງ​ແຕ່​ໃນ Windows​,
ບ່ອນທີ່ມັນໃຊ້ Volume Shadow Copy Service (VSS). ການນໍາໃຊ້ທາງເລືອກນີ້, ທ່ານສາມາດເຮັດໄດ້
ສ້າງການສໍາຮອງຂໍ້ມູນທີ່ສອດຄ່ອງຂອງປະລິມານລະບົບຂອງລະບົບ Windows ແລ່ນໂດຍບໍ່ມີການ
ແລ່ນເຂົ້າໄປໃນບັນຫາກັບໄຟລ໌ທີ່ຖືກລັອກ. ເພື່ອໃຫ້ພາບຖ່າຍ VSS ປະສົບຜົນສໍາເລັດ
ສ້າງ, wimlib-imagex ຕ້ອງໄດ້ຮັບການດໍາເນີນການເປັນ Administrator, ແລະມັນບໍ່ສາມາດດໍາເນີນການໄດ້
ໂຫມດ WoW64 (ie ຖ້າ Windows ເປັນ 64-bit, ຫຼັງຈາກນັ້ນ wimlib-imagex ຈະຕ້ອງເປັນ 64-bit ເຊັ່ນກັນ).

ຫມາຍເຫດ

wimlib-imagex ເພີ່ມເຕີມ ບໍ່ຮອງຮັບການເພີ່ມຮູບພາບໃສ່ກັບ WIM ທີ່ແບ່ງປັນ.

ຍົກເວັ້ນເມື່ອໃຊ້ --ບໍ່ປອດໄພ-ກະທັດຮັດ, ມັນປອດໄພທີ່ຈະເອົາລູກອອກ wimlib-imagex ເພີ່ມເຕີມ ຄໍາສັ່ງ
partway ຜ່ານ; ຢ່າງໃດກໍຕາມ, ຫຼັງຈາກດໍາເນີນການນີ້, ມັນແມ່ນແນະນໍາໃຫ້ດໍາເນີນການ wimlib-imagex
ເພີ່ມປະສິດທິ ເພື່ອເອົາຂໍ້ມູນໃດໆທີ່ຕິດຢູ່ກັບໄຟລ໌ WIM ຕົວຈິງແຕ່ຍັງບໍ່ທັນໄດ້
ຖືກລວມເຂົ້າກັບໂຄງສ້າງຂອງ WIM, ເວັ້ນເສຍແຕ່ WIM ຈະຖືກສ້າງໃຫມ່ຢ່າງສົມບູນ (ຕົວຢ່າງ
ກັບ -- ສ້າງ​ໃຫມ່​), ໃນ​ກໍ​ລະ​ນີ​ທີ່​ທ່ານ​ຄວນ​ຈະ​ລົບ​ໄຟລ​໌​ຊົ່ວ​ຄາວ​ທີ່​ຍັງ​ເຫຼືອ​.

wimlib-imagex ສ້າງ WIM ທີ່ເຂົ້າກັນໄດ້ກັບຊອບແວຂອງ Microsoft (WIMGAPI, ImageX, DISM),
ມີ​ຄໍາ​ເຕືອນ​ບາງ​ຢ່າງ​:

· ກັບ wimlib-imagex ໃນລະບົບທີ່ຄ້າຍຄືກັບ UNIX, ມັນເປັນໄປໄດ້ທີ່ຈະສ້າງຮູບພາບ WIM
ມີໄຟລ໌ທີ່ມີຊື່ແຕກຕ່າງກັນພຽງແຕ່ໃນກໍລະນີ, ຫຼືໄຟລ໌ທີ່ມີຊື່ປະກອບດ້ວຍ
ຕົວອັກສອນ ':', '*', '?', '"', '<', '>', '|', ຫຼື '\', ເຊິ່ງໃຊ້ໄດ້ໃນ POSIX-
ລະບົບໄຟລ໌ທີ່ສອດຄ່ອງກັບແຕ່ບໍ່ແມ່ນ Windows. ໄດ້ຮັບການເຕືອນວ່າໄຟລ໌ດັ່ງກ່າວຈະບໍ່ເປັນ
ສະກັດໂດຍຄ່າເລີ່ມຕົ້ນໂດຍສະບັບ Windows ຂອງ wimlib-imagex, ແລະ (ຮ້າຍແຮງກວ່າເກົ່າ)
ImageX ຂອງ Microsoft ສາມາດສັບສົນໂດຍຊື່ດັ່ງກ່າວແລະຢຸດເຊົາການສະກັດຮູບພາບອອກ
ຜ່ານ. (ບາງທີມັນຄຸ້ມຄ່າທີ່ຈະຊີ້ໃຫ້ເຫັນວ່າລະບົບໄຟລ໌ເລີ່ມຕົ້ນຂອງ Windows ຂອງຕົນເອງ,
NTFS, ສະຫນັບສະຫນູນລັກສະນະເຫຼົ່ານີ້, ເຖິງແມ່ນວ່າ Windows ບໍ່ໄດ້!)

· Pipable WIMs ບໍ່ເຂົ້າກັນໄດ້ກັບຊອບແວຂອງ Microsoft. Pipable WIMs ຖືກສ້າງຂື້ນ
ພຽງແຕ່ຖ້າວ່າ WIMFILE ໄດ້ຖືກລະບຸເປັນ "-" (ຜົນຜະລິດມາດຕະຖານ) ຫຼືຖ້າຫາກວ່າ --pipable ທຸງແມ່ນ
ລະບຸ.

· WIMs ທີ່ຖືກຈັບດ້ວຍຂະຫນາດ chunk ທີ່ບໍ່ແມ່ນຄ່າເລີ່ມຕົ້ນ (ກັບ --chunk-size ທາງ​ເລືອກ​) ຫຼື​ເປັນ​ແຂງ​
ຮວບຮວມ (ກັບ --ແຂງ ທາງເລືອກ) ຫຼືດ້ວຍການບີບອັດ LZMS (ດ້ວຍ --ບີບອັດ=LZMS ຫຼື
--ບີບອັດ=recovery) ມີລະດັບຄວາມເຂົ້າກັນໄດ້ທີ່ແຕກຕ່າງກັນກັບຊອບແວຂອງ Microsoft.
ໂດຍທົ່ວໄປແລ້ວ, ຊອບແວຂອງ Microsoft ຮຸ່ນຫຼ້າສຸດແມ່ນເຂົ້າກັນໄດ້ຫຼາຍຂຶ້ນ.

ຕົວຢ່າງ

ຕົວຢ່າງທໍາອິດ: ສ້າງໃຫມ່ WIM 'mywim.wim' ດ້ວຍການບີບອັດ LZX ("ສູງສຸດ") ທີ່ຈະ
ປະກອບມີຮູບພາບທີ່ຖືກບັນທຶກຂອງຕົ້ນໄມ້ໄດເລກະທໍລີ 'somedir'. ໃຫ້ສັງເກດວ່າຊື່ຮູບພາບຕ້ອງການ
ບໍ່​ໄດ້​ຖືກ​ລະ​ບຸ​ໄວ້​ແລະ​ຈະ​ຕັ້ງ​ຄ່າ​ເລີ່ມ​ຕົ້ນ​ເປັນ 'somedir'​:

wimlib-imagex ຈັບ somedir mywim.wim

ຫຼື, ຖ້າວ່າ wimcapture ການເຊື່ອມຕໍ່ແຂງຫຼືໄຟລ໌ batch ໄດ້ຖືກຕິດຕັ້ງ, ແບບຟອມຫຍໍ້ສາມາດ
ຖືກນໍາໃຊ້:

wimcapture somedir mywim.wim

ຕົວຢ່າງທີ່ຍັງເຫຼືອຈະໃຊ້ຮູບແບບຍາວ, ຢ່າງໃດກໍຕາມ. ຕໍ່ໄປ, ຕື່ມຮູບພາບຂອງ a
ຕົ້ນໄມ້ໄດເລກະທໍລີທີ່ແຕກຕ່າງກັນກັບ WIM ທີ່ສ້າງຂຶ້ນຂ້າງເທິງ:

wimlib-imagex ເພີ່ມເຕີມອີກອັນໜຶ່ງ mywim.wim

ງ່າຍພຽງພໍ, ແລະຕົວຢ່າງຂ້າງເທິງຂອງຕົ້ນໄມ້ໄດເລກະທໍລີຮູບພາບເຮັດວຽກຢູ່ໃນທັງສອງແບບ UNIX
ລະ​ບົບ​ແລະ Windows​. ຕໍ່ໄປ, ບັນທຶກ WIM ທີ່ມີຕົວເລືອກທີ່ບໍ່ແມ່ນຄ່າເລີ່ມຕົ້ນຫຼາຍອັນ, ລວມທັງ
ການບີບອັດ XPRESS ("ໄວ"), ຕາຕະລາງຄວາມສົມບູນ, ບໍ່ມີການລົບກວນກັບການເຊື່ອມໂຍງສັນຍາລັກຢ່າງແທ້ຈິງ,
ແລະຊື່ຮູບພາບແລະຄໍາອະທິບາຍ:

wimlib-imagex ຈັບ somedir mywim.wim --compress=fast \
--check --norpfix "ຊື່ບາງອັນ" "ລາຍລະອຽດບາງອັນ"

ບັນທຶກປະລິມານ NTFS ທັງໝົດເຂົ້າໃນໄຟລ໌ WIM ໃໝ່ ແລະຕັ້ງຊື່ຮູບພາບວ່າ "Windows 7". ສຸດ
ລະບົບທີ່ຄ້າຍຄືກັບ UNIX, ນີ້ຮຽກຮ້ອງໃຫ້ມີການໃຊ້ໂຫມດພິເສດທີ່ອະທິບາຍໄວ້ໃນ NTFS VOLUME ຮູບພາບ
(UNIX) ບ່ອນທີ່ ແຫຼ່ງຂໍ້ມູນ ເປັນໄຟລ໌ ຫຼືອຸປະກອນບລັອກທີ່ມີລະບົບໄຟລ໌ NTFS:

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

ຫຼື, ໃນ Windows, ເພື່ອເກັບກໍາປະລິມານ NTFS ເຕັມ, ແທນທີ່ຈະຕ້ອງການລະບຸຮາກ
ໄດເລກະທໍລີຂອງປະລິມານທີ່ຕິດຕັ້ງ, ສໍາລັບການຍົກຕົວຢ່າງ:

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

ຄືກັນກັບຕົວຢ່າງຂ້າງເທິງດ້ວຍການຈັບປະລິມານ NTFS ຈາກ wimlib-imagex ແລ່ນຢູ່ໃນ UNIX-
ຄືກັບລະບົບ, ແຕ່ຈັບ WIM ໃນຮູບແບບ "pipable" ສະເພາະ wimlib ທີ່ສາມາດທໍ່ໄດ້.
to wimlib-imagex ນໍາໃຊ້:

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

ຄືກັນກັບຂ້າງເທິງ, ແຕ່ແທນທີ່ຈະຂຽນ WIM pipable ກັບໄຟລ໌ "windows7.wim", ຂຽນມັນ.
ໂດຍກົງກັບຜົນຜະລິດມາດຕະຖານໂດຍຜ່ານທໍ່ເຂົ້າໄປໃນບາງໂຄງການອື່ນໆ "someprog", ເຊິ່ງ
ສໍາລັບຕົວຢ່າງ, ສາມາດເປັນໂຄງການຫຼືສະຄິບທີ່ຖ່າຍທອດຂໍ້ມູນໄປຍັງເຄື່ອງແມ່ຂ່າຍ. ໃຫ້ສັງເກດວ່າ
--pipable ບໍ່ຈໍາເປັນຕ້ອງລະບຸຢ່າງຊັດເຈນເມື່ອນໍາໃຊ້ຜົນຜະລິດມາດຕະຖານເປັນ "ໄຟລ໌" WIM:

wimlib-imagex capture /dev/sda2 - "Windows 7" | ບາງໂປຣແກມ

ໃຊ້ wimlib-imagex-append ອອນໄລນ໌ໂດຍໃຊ້ບໍລິການ onworks.net