.TH WIMCAPTURE "1" "January 2026" "wimlib 1.14.5" "دستورات کاربر"
.SH "نام (NAME)"
wimcapture, wimappend \- ضبط یا الصاق یک ایمیج WIM
.SH "خلاصه دستور (SYNOPSIS)"
\fBwimcapture\fR \fISOURCE\fR \fIWIMFILE\fR [\fIIMAGE_NAME\fR \ [\fIIMAGE_DESC\fR]] [\fIOPTION\fR...]
.br
\fBwimappend\fR \fISOURCE\fR \fIWIMFILE\fR [\fIIMAGE_NAME\fR \ [\fIIMAGE_DESC\fR]] [\fIOPTION\fR...]
.SH "توضیحات (DESCRIPTION)"
دستورهای \fBwimcapture\fR (معادل: \fBwimlib-imagex capture\fR) و
\fBwimappend\fR (معادل: \fBwimlib-imagex append\fR) یک ایمیج جدید
Windows Imaging (WIM) ایجاد (یا «ضبط») می‌کنند. \fBwimcapture\fR یک بایگانی WIM
جدید در \fIWIMFILE\fR برای نگهداری ایمیج جدید ایجاد می‌کند، در حالی که \fBwimappend\fR
ایمیج را به بایگانی WIM موجود \fIWIMFILE\fR اضافه می‌کند (یا با گزینه \fB--create\fR،
در صورت نیاز آن را ایجاد می‌نماید).
.PP
پارامتر \fISOURCE\fR مکان فایل‌هایی را که قرار است ایمیج WIM از آن‌ها ساخته شود مشخص می‌کند.
اگر \fISOURCE\fR یک دایرکتوری یا پیوند نمادین اشاره‌کننده به یک دایرکتوری باشد،
ایمیج مطابق با \fBضبط دایرکتوری در یونیکس (DIRECTORY CAPTURE - UNIX)\fR یا \fBضبط دایرکتوری در ویندوز (DIRECTORY CAPTURE - WINDOWS)\fR از آن دایرکتوری ضبط می‌شود.
همچنین اگر گزینه \fB--source-list\fR مشخص شده باشد، \fISOURCE\fR به عنوان فایلی حاوی
فهرستی از فایل‌ها و دایرکتوری‌ها برای گنجاندن در ایمیج تفسیر می‌گردد. علاوه بر این،
اگر \fISOURCE\fR یک دستگاه بلوکی یونیکس باشد، ایمیج از حجم NTFS موجود روی آن
مطابق با \fBضبط حجم NTFS در یونیکس (NTFS VOLUME CAPTURE - UNIX)\fR ضبط می‌شود.
.PP
پارامترهای \fIIMAGE_NAME\fR و \fIIMAGE_DESC\fR نام و توضیحات اختصاص‌یافته به ایمیج جدید را مشخص می‌کنند.
اگر \fIIMAGE_NAME\fR تعیین نشود، به‌طور پیش‌فرض از بخش نام فایل \fISOURCE\fR استفاده می‌شود
و در صورت لزوم یک پسوند یکتا به آن اضافه می‌گردد. در غیر این صورت، \fIIMAGE_NAME\fR باید
نامی باشد که قبلاً توسط ایمیجی در \fIWIMFILE\fR استفاده نشده است، یا یک رشته خالی برای
ایجاد یک ایمیج بدون نام باشد. اگر \fIIMAGE_DESC\fR مشخص نشود، هیچ توضیحی به ایمیج جدید داده نخواهد شد.
.PP
اگر \fIWIMFILE\fR به صورت "-" مشخص شود، گزینه \fB--pipable\fR فرض شده و
یک WIM پایپ‌پذیر در خروجی استاندارد نوشته می‌شود (این یک قابلیت افزوده wimlib است).
.SH "ضبط دایرکتوری در یونیکس (DIRECTORY CAPTURE - UNIX)"
در سیستم‌های شبه‌یونیکس، اگر \fISOURCE\fR یک دایرکتوری یا یک پیوند نمادین
به یک دایرکتوری را مشخص کند، ایمیج WIM از آن دایرکتوری ضبط خواهد شد. دایرکتوری
می‌تواند روی هر نوع فایل‌سیستمی قرار داشته باشد و از نقاط اتصال (mountpoints) نیز پیروی می‌شود.
در این حالت، انواع اطلاعات زیر ضبط می‌شوند:
.IP \[bu] 4
دایرکتوری‌ها و فایل‌های معمولی، و محتویات فایل‌های معمولی
.IP \[bu]
پیوندهای سخت (Hard links)
.IP \[bu]
پیوندهای نمادین (بدون افت کیفیت به نقاط بازپارس یا Reparse Points ویندوز ترجمه می‌شوند)
.IP \[bu]
زمان‌های آخرین تغییر (mtime) و آخرین دسترسی (atime) با دقت ۱۰۰ نانوثانیه
.IP \[bu]
فایل‌هایی که به نظر خلوت (sparse) می‌رسند به همین عنوان علامت‌گذاری می‌شوند، اما داده‌های کامل آن‌ها همچنان ذخیره خواهد شد و مشمول فشرده‌سازی معمول قرار می‌گیرد.
.IP \[bu]
با گزینه \fB--unix-data\fR: مجوزهای استاندارد فایل یونیکس (مالک، گروه و حالت دسترسی)
.IP \[bu]
با گزینه \fB--unix-data\fR: گره‌های دستگاه (device nodes)، پایپ‌های نام‌گذاری‌شده (named pipes) و سوکت‌ها
.IP \[bu]
با گزینه \fB--unix-data\fR: ویژگی‌های گسترش‌یافته (extended attributes - فقط در لینوکس)
.PP
هیچ پشتیبانی برای ذخیره زمان‌های آخرین تغییر وضعیت (ctime) یا اطلاعات پیوند سخت برای پیوندهای نمادین وجود ندارد (هر پیوند نمادین به عنوان یک فایل مجزا ذخیره می‌شود). همچنین، نام فایل‌ها و مقصدهای پیوند نمادین که به شکل UTF-8 معتبر همراه با کدهای جایگزین (surrogate codepoints) نباشند پشتیبانی نمی‌شوند. توجه داشته باشید که اگر فایل‌سیستمی حاوی نام فایل‌ها با رمزگذاری چندبایتی دیگری مانند ISO-8859-1 دارید و می‌خواهید آن را با wimlib بایگانی کنید، ممکن است بتوانید آن را با گزینه‌ای سوار (mount) کنید که باعث شود نام فایل‌های آن به صورت UTF-8 نمایش داده شوند.
.SH "ضبط حجم NTFS در یونیکس (NTFS VOLUME CAPTURE - UNIX)"
در سیستم‌های شبه‌یونیکس، \fISOURCE\fR همچنین می‌تواند به عنوان یک دستگاه بلوکی (مانند /dev/sda3) حاوی یک حجم NTFS سوارنشده مشخص شود. در این حالت، \fBwimcapture\fR از libntfs-3g برای ضبط یک ایمیج WIM از دایرکتوری ریشه حجم NTFS استفاده می‌کند. در این حالت، تا حد امکان داده‌ها و متادیتاها ضبط می‌شوند، از جمله متادیتای اختصاصی NTFS و ویندوز:
.IP \[bu] 4
تمام جریان‌های داده (data streams) تمام فایل‌های رمزگذاری‌نشده، از جمله جریان داده بدون نام و همچنین تمام جریان‌های داده نام‌گذاری‌شده.
.IP \[bu]
نقاط بازپارس (Reparse points). برای جزئیات به بخش \fBنقاط بازپارس و پیوندهای نمادین (REPARSE POINTS AND SYMLINKS)\fR مراجعه کنید.
.IP \[bu]
مهر زمانی (timestamp) ایجاد، دسترسی و تغییر فایل و دایرکتوری، با استفاده از تفکیک‌پذیری بومی NTFS با دقت ۱۰۰ نانوثانیه.
.IP \[bu]
توصیف‌کننده‌های امنیت ویندوز (Windows security descriptors)، شامل تمام اجزا (مالک، گروه، DACL و SACL).
.IP \[bu]
فلگ‌های ویژگی فایل DOS/ویندوز.
.IP \[bu]
تمام نام‌های همه فایل‌ها، از جمله نام‌ها در فضای نام Win32، فضای نام DOS، فضای نام Win32+DOS و فضای نام POSIX. این شامل پیوندهای سخت نیز می‌شود.
.IP \[bu]
شناسه‌های شیء (Object IDs).
.PP
با این حال، محدودیت‌های اصلی این حالت عبارتند از:
.IP \[bu] 4
فایل‌های رمزگذاری‌شده مستثنی هستند.
.IP \[bu]
ویژگی‌های گسترش‌یافته (EAs) هنوز ذخیره نمی‌شوند.
.IP \[bu]
فایل‌های خلوت (sparse files) به همین عنوان علامت‌گذاری می‌شوند، اما داده‌های کامل آن‌ها همچنان با اعمال فشرده‌سازی معمول ذخیره خواهد شد.
.IP \[bu]
برخی از انواع نقاط بازپارس به صورت شفاف توسط ویندوز ارجاع‌زدایی می‌شوند اما توسط NTFS-3G ارجاع‌زدایی نمی‌شوند. بخش \fBنقاط بازپارس و پیوندهای نمادین (REPARSE POINTS AND SYMLINKS)\fR را ببینید.
.PP
توجه داشته باشید که این حالت مستقیماً از libntfs-3g استفاده می‌کند، بدون اینکه از درایور \fBntfs-3g\fR(8) عبور کند. بنابراین، هیچ پشتیبانی ویژه‌ای برای ضبط ایمیج WIM از دایرکتوری‌ای که یک فایل‌سیستم NTFS با استفاده از \fBntfs-3g\fR(8) روی آن سوار شده است وجود ندارد؛ ابتدا باید آن را پیاده (unmount) کنید. همچنین هیچ پشتیبانی برای ضبط یک زیردایرکتوری از حجم NTFS وجود ندارد؛ شما فقط می‌توانید کل حجم را ضبط کنید.
.SH "ضبط دایرکتوری در ویندوز (DIRECTORY CAPTURE - WINDOWS)"
در ویندوز، \fBwimcapture\fR و \fBwimappend\fR به صورت بومی از داده‌های اختصاصی ویندوز و NTFS پشتیبانی می‌کنند. بنابراین عملکرد آن‌ها مشابه دستورهای متناظر ImageX یا DISM مایکروسافت است. برای بهترین نتایج، دایرکتوری ضبط‌شده باید روی یک حجم NTFS باشد و برنامه با دسترسی مدیر سیستم (Administrator) اجرا شود؛ با این حال، فایل‌سیستم‌های غیر NTFS و اجرا بدون دسترسی Administrator نیز با وجود برخی محدودیت‌ها پشتیبانی می‌شوند.
.PP
در ویندوز، \fBwimcapture\fR و \fBwimappend\fR تلاش می‌کنند تا حد امکان داده‌ها و متادیتاها را ضبط نمایند، از جمله:
.IP \[bu] 4
تمام جریان‌های داده (data streams) تمام فایل‌ها.
.IP \[bu]
نقاط بازپارس (Reparse points)، در صورت پشتیبانی توسط فایل‌سیستم منبع. برای جزئیات به بخش \fBنقاط بازپارس و پیوندهای نمادین (REPARSE POINTS AND SYMLINKS)\fR مراجعه کنید.
.IP \[bu]
مهرهای زمانی ایجاد، دسترسی و تغییر فایل و دایرکتوری. این موارد با تفکیک‌پذیری بومی مهر زمانی ویندوز یعنی ۱۰۰ نانوثانیه ذخیره می‌شوند.
.IP \[bu]
توصیف‌کننده‌های امنیت (Security descriptors)، در صورت پشتیبانی توسط فایل‌سیستم منبع و عدم مشخص شدن گزینه \fB--no-acls\fR. نکته: هنگام اجرا بدون دسترسی Administrator، توصیف‌کننده‌های امنیت ممکن است فقط به صورت جزئی ضبط شوند (گزینه \fB--strict-acls\fR را ببینید).
.IP \[bu]
ویژگی‌های فایل، شامل مخفی (hidden)، خلوت (sparse)، فشرده (compressed)، رمزگذاری‌شده (encrypted) و غیره. فایل‌های رمزگذاری‌شده به صورت رمزگذاری‌شده ذخیره خواهند شد نه متن ساده. فایل‌های فشرده‌شده به صورت شفاف، به عنوان غیرفشرده خوانده می‌شوند و مشمول فشرده‌سازی خود WIM ذخیره می‌گردند. هیچ رفتار ویژه‌ای برای ذخیره فایل‌های خلوت وجود ندارد، اما به احتمال زیاد به حجم کمی فشرده می‌شوند.
.IP \[bu]
نام‌های DOS (8.3) فایل‌ها؛ با این حال، عدم موفقیت در خواندن آن‌ها به عنوان یک وضعیت خطا در نظر گرفته نمی‌شود.
.IP \[bu]
پیوندهای سخت، در صورت پشتیبانی توسط فایل‌سیستم منبع.
.IP \[bu]
شناسه‌های شیء (Object IDs)، در صورت پشتیبانی توسط فایل‌سیستم منبع.
.IP \[bu]
ویژگی‌های گسترش‌یافته (EAs)، در صورت پشتیبانی توسط فایل‌سیستم منبع.
.SH "نقاط بازپارس و پیوندهای نمادین (REPARSE POINTS AND SYMLINKS)"
یک «پیوند نمادین» (یا «symlink») یک فایل ویژه است که به فایل یا دایرکتوری دیگری «اشاره می‌کند». در ویندوز، یک «نقطه بازپارس» (reparse point) تعمیمی از پیوند نمادین است که اجازه می‌دهد دسترسی به یک فایل یا دایرکتوری به شیوه‌ای پیچیده‌تر تغییر مسیر یابد. ویندوز از نقاط بازپارس برای پیاده‌سازی پیوندهای نمادین استفاده می‌کند و گاهی از آن‌ها برای قابلیت‌های متنوع دیگر نیز بهره می‌برد. معمولاً برنامه‌ها می‌توانند انتخاب کنند که آیا می‌خواهند نقاط بازپارس و پیوندهای نمادین را «ارجاع‌زدایی» (dereference) کنند یا خیر.
.PP
رفتار پیش‌فرض \fBwimcapture\fR این است که نقاط بازپارس و پیوندهای نمادین ارجاع‌زدایی \fIنمی‌شوند\fR، به این معنی که خود نقاط بازپارس یا پیوندهای نمادین در بایگانی ذخیره می‌شوند، نه فایل‌ها یا داده‌هایی که به آن‌ها اشاره می‌کنند. گزینه \fB--dereference\fR وجود دارد، اما در حال حاضر فقط توسط نسخه یونیکس \fBwimcapture\fR روی فایل‌سیستم‌های یونیکس پشتیبانی می‌شود (هنوز برای فایل‌سیستم‌های ویندوز پیاده‌سازی نشده است).
.PP
ویندوز همچنین با انواع خاصی از نقاط بازپارس به صورت ویژه رفتار می‌کند. به عنوان مثال، برنامه‌های ویندوزی که فایل‌های داده‌های تکراری‌زدوده‌شده (deduplicated)، فایل‌های مبتنی بر WIM یا فایل‌های فشرده سیستمی را می‌خوانند، همیشه داده‌های ارجاع‌زدایی‌شده را می‌بینند، حتی اگر درخواست عدم آن را داشته باشند. بنابراین، \fBwimcapture\fR در ویندوز این فایل‌ها را به صورت ارجاع‌زدایی‌شده ذخیره می‌کند، نه به عنوان نقاط بازپارس. اما \fBwimcapture\fR در یونیکس در حالت NTFS-3G نمی‌تواند این فایل‌ها را ارجاع‌زدایی کند و در عوض آن‌ها را به عنوان نقاط بازپارس ذخیره خواهد کرد. این تفاوت می‌تواند در موقعیت‌های خاصی مهم باشد، مثلاً هنگام ضبط فایل‌های deduplicated که برای خوانده شدن پس از استخراج، نیازمند وجود مخزن قطعات (chunk store) نیز هستند.
.SH "گزینه‌ها (OPTIONS)"
.TP 6
\fB--boot\fR
علامت‌گذاری ایمیج جدید به عنوان ایمیج «قابل بوت» (bootable) در WIM. ایمیج «قابل بوت» ایمیجی است که بوت‌لودر ویندوز هنگام بارگذاری Windows PE از WIM از آن استفاده خواهد کرد.
.TP
\fB--check\fR
گنجاندن اطلاعات یکپارچگی اضافی در WIM حاصل. با \fBwimappend\fR، یکپارچگی WIM نیز قبل از الصاق به آن بررسی می‌شود. همچنین یکپارچگی هر WIM مشخص‌شده با \fB--update-of\fR و/یا \fB--delta-from\fR را بررسی می‌کند.
.TP
\fB--include-integrity\fR
گنجاندن اطلاعات یکپارچگی اضافی در WIM حاصل؛ یعنی مانند \fB--check\fR اما بدون انجام بررسی قبلی.
.TP
\fB--compress\fR=\fITYPE\fR[:\fILEVEL\fR]
در \fBwimcapture\fR، از قالب فشرده‌سازی مشخص‌شده در فایل WIM جدید استفاده می‌کند. پارامتر \fITYPE\fR می‌تواند "none"، "XPRESS" (نام مستعار: "fast")، "LZX" (نام مستعار: "maximum") یا "LZMS" (نام مستعار: "recovery") باشد. حساسیت به حروف بزرگ و کوچک در \fITYPE\fR وجود ندارد. حالت پیش‌فرض "LZX" است.
.IP ""
همچنین می‌توانید به صورت اختیاری یک \fILEVEL\fR فشرده‌سازی عدد صحیح را مشخص کنید. سطح فشرده‌سازی مشخص می‌کند که الگوریتم فشرده‌سازی برای \fITYPE\fR تعیین‌شده با چه شدتی برای فشرده‌سازی داده‌ها کار خواهد کرد. مقادیر به گونه‌ای مقیاس‌بندی شده‌اند که ۲۰ فشرده‌سازی سریع، ۵۰ فشرده‌سازی متوسط و ۱۰۰ فشرده‌سازی بالا است. با این حال، می‌توانید هر مقداری را انتخاب کنید و محدود به این مقادیر خاص نیستید. مقدار پیش‌فرض ۵۰ است.
.IP ""
این گزینه فقط بر نوع فشرده‌سازی استفاده‌شده در منابع WIM غیریکپارچه (non-solid) تأثیر می‌گذارد. اگر در حال ساخت یک WIM یکپارچه (solid) با استفاده از گزینه \fB--solid\fR هستید، احتمالاً در عوض به گزینه \fB--solid-compress\fR نیاز دارید.
.IP ""
اگر فشرده‌سازی LZMS را انتخاب می‌کنید، احتیاط کنید. این حالت با wimlib قبل از نسخه v1.6.0، با WIMGAPI قبل از ویندوز ۸، با DISM قبل از ویندوز ۸.۱ و با 7-Zip قبل از نسخه v15.12 سازگار نیست. همچنین توجه داشته باشید که انتخاب فشرده‌سازی LZMS به طور خودکار به معنای فشرده‌سازی حالت یکپارچه (solid) نیست، بر خلاف آنچه در DISM رخ می‌دهد. اگر می‌خواهید یک WIM یکپارچه یا "فایل ESD" ایجاد کنید، از \fB--solid\fR استفاده نمایید.
.TP
\fB--chunk-size\fR=\fISIZE\fR
در \fBwimcapture\fR، از اندازه تکه فشرده‌سازی \fISIZE\fR بایت استفاده می‌کند. اندازه تکه فشرده‌سازی بزرگتر منجر به نسبت فشرده‌سازی بهتری می‌شود. wimlib بسته به نوع فشرده‌سازی از اندازه‌های تکه مختلفی پشتیبانی می‌کند:
.RS
.IP \[bu] 2
XPRESS: 4K, 8K, 16K, 32K, 64K
.IP \[bu]
LZX: 32K, 64K, 128K, 256K, 512K, 1M, 2M
.IP \[bu]
LZMS: 32K, 64K, 128K, 256K, 512K, 1M, 2M, 4M, 8M, 16M, 32M, 64M, 128M, 256M, 512M, 1G
.RE
.IP ""
می‌توانید عدد کامل را وارد کنید (مانند 32768)، یا از یکی از پسوندهای K، M یا G استفاده نمایید. پسوندهای KiB، MiB و GiB نیز پذیرفته می‌شوند.
.IP ""
این گزینه فقط بر اندازه تکه مورد استفاده در منابع WIM غیریکپارچه تأثیر می‌گذارد. اگر در حال ایجاد یک WIM یکپارچه هستید (با استفاده از گزینه \fB--solid\fR)، احتمالاً در عوض به \fB--solid-chunk-size\fR نیاز دارید.
.IP ""
در صورتی که سازگاری با نرم‌افزارهای WIM مایکروسافت مد نظر است با احتیاط از این گزینه استفاده کنید، زیرا نرم‌افزارهای آن‌ها پشتیبانی محدودی از اندازه‌های تکه غیرپیش‌فرض دارند.
.TP
\fB--solid\fR
در \fBwimcapture\fR، یک فایل WIM «یکپارچه» (solid) ایجاد می‌کند که فایل‌ها را با هم فشرده می‌سازد نه به صورت مستقل. این امر منجر به نسبت فشرده‌سازی به مراتب بهتری می‌شود، اما به قیمت فشرده‌سازی کند با مصرف حافظه بسیار بالا، سازگاری کاهش‌یافته و دسترسی تصادفی کند به فایل WIM حاصل تمام می‌شود.
.IP ""
به‌طور پیش‌فرض این گزینه فشرده‌سازی یکپارچه LZMS را فعال می‌کند، در نتیجه فایلی معادل فایلی که با گزینه \fB/compress\fR:\fIrecovery\fR در DISM ساخته شده ایجاد می‌نماید. به چنین فایل‌هایی "فایل‌های ESD" نیز گفته می‌شود و برای نخستین بار در ویندوز ۸ توسط WIMGAPI، در ویندوز ۸.۱ توسط DISM و در نسخه 15.12 توسط 7-Zip پشتیبانی شدند.
.TP
\fB--solid-compress\fR=\fITYPE\fR[:\fILEVEL\fR]
مشابه \fB--compress\fR، اما نوع فشرده‌سازی مورد استفاده در منابع یکپارچه (solid) را تعیین می‌کند. حالت پیش‌فرض، فشرده‌سازی LZMS است. این گزینه تنها زمانی اعمال می‌شود که \fB--solid\fR نیز مشخص شده باشد.
.TP
\fB--solid-chunk-size\fR=\fISIZE\fR
مشابه \fB--chunk-size\fR، اما اندازه تکه مورد استفاده در منابع یکپارچه را تعیین می‌کند. مقدار پیش‌فرض، با فرض فشرده‌سازی LZMS، برابر 64MiB (67108864) است؛ این مقدار نیازمند حدود 640MiB حافظه به ازای هر ریسه (thread) است. این گزینه تنها زمانی اعمال می‌شود که \fB--solid\fR نیز مشخص شده باشد. نکته: نرم‌افزارهای WIM مایکروسافت با اندازه‌های تکه LZMS بزرگتر از 64MiB سازگار نیستند.
.TP
\fB--threads\fR=\fINUM_THREADS\fR
تعداد ریسه‌ها (threads) برای استفاده در فشرده‌سازی داده‌ها. پیش‌فرض: تشخیص خودکار (تعداد پردازنده‌های در دسترس).
.TP
\fB--rebuild\fR
در \fBwimappend\fR، به جای الحاق داده‌های جدید به انتهای فایل WIM، کل فایل WIM را بازسازی می‌کند. بازسازی WIM کندتر است، اما مقداری فضا را که در غیر این صورت به عنوان یک حفره در WIM باقی می‌ماند، ذخیره می‌کند. همچنین به \fBwimoptimize\fR(1) مراجعه کنید.
.TP
\fB--flags\fR=\fIEDITIONID\fR
مشخص کردن یک رشته برای استفاده در عنصر <FLAGS> داده‌های XML برای ایمیج جدید.
.TP
\fB--image-property\fR \fINAME\fR=\fIVALUE\fR
اختصاص یک ویژگی دلخواه به ایمیج جدید در سند XML فایل WIM. پارامتر \fIVALUE\fR رشته‌ای است که به عنوان مقدار ویژگی تنظیم می‌شود. \fINAME\fR نام ویژگی ایمیج است، برای مثال "NAME"، "DESCRIPTION" یا "TOTALBYTES". نام می‌تواند حاوی اسلش رو به جلو باشد تا یک عنصر تو در توی XML را نشان دهد؛ به عنوان مثال "WINDOWS/VERSION/BUILD" نشان‌دهنده عنصر BUILD قرارگرفته در درون عنصر VERSION در درون عنصر WINDOWS است. یک عدد در داخل کروشه می‌تواند برای نشان دادن یکی از چندین عنصر با نام یکسان استفاده شود؛ به عنوان مثال "WINDOWS/LANGUAGES/LANGUAGE[2]" نشان‌دهنده دومین عنصر "LANGUAGE" تو در تو در درون عنصر "WINDOWS/LANGUAGES" است. هنگام اضافه کردن فهرستی از عناصر به این روش، آن‌ها باید به ترتیب متوالی مشخص شوند. توجه داشته باشید که نام عناصر به حروف بزرگ و کوچک حساس هستند. این گزینه می‌تواند چندین بار مشخص شود.
.TP
\fB--dereference\fR
(فقط در سیستم‌های شبه‌یونیکس) دنبال کردن پیوندهای نمادین و بایگانی فایل‌هایی که به آن‌ها اشاره می‌کنند، به جای بایگانی خود پیوندها.
.TP
\fB--config\fR=\fIFILE\fR
یک فایل پیکربندی (با کدگذاری UTF-8 یا UTF-16LE؛ اسکی ساده نیز کار می‌کند) برای ضبط ایمیج جدید مشخص می‌کند. فایل پیکربندی فایل‌هایی را تعیین می‌کند که باید در حین ضبط ایمیج رفتار ویژه‌ای با آن‌ها شود.
.IP ""
قالب فایل پیکربندی به سبک INI است؛ به این صورت که در بخش‌های داخل کروشه مرتب شده است. در حال حاضر، بخش‌های زیر شناسایی می‌شوند:
.RS
.IP \[bu] 4
[ExclusionList] --- حاوی فهرستی از الگوهای تطبیق مسیر (path globs) برای استثنا کردن از ضبط است. اگر با یک دایرکتوری تطبیق یابد، هم دایرکتوری و هم محتویات آن مستثنی می‌شوند.
.IP \[bu]
[ExclusionException] --- حاوی فهرستی از الگوهای تطبیق مسیر برای گنجاندن است، حتی زمانی که فایل یا دایرکتوری با الگویی در [ExclusionList] نیز مطابقت داشته باشد. اگر با یک دایرکتوری تطبیق یابد، تمام محتویات آن نیز گنجانده می‌شوند. فایل‌ها یا دایرکتوری‌های \fIدرون\fR یک دایرکتوری مستثنی‌شده توسط [ExclusionList] حتی ممکن است با استفاده از این بخش گنجانده شوند، اگرچه در حال حاضر این ویژگی فقط برای الگوهای مطلق (آن‌هایی که با "/" یا "\\" شروع می‌شوند) کار می‌کند؛ برای مثال، "/dir/file" می‌تواند گنجانده شود در حالی که "/dir" می‌تواند مستثنی شود، اما گنجاندن ساده "file" در آن حالت کار نخواهد کرد.
.IP \[bu]
[PrepopulateList] --- این بخش بر ضبط تأثیری ندارد، اما اگر ایمیج بعداً با \fB--wimboot\fR اعمال شود، این‌ها الگوهای فایل‌هایی هستند که باید به صورت عادی استخراج شوند، نه به عنوان "فایل‌های نشانگر" WIMBoot. اگر با یک دایرکتوری تطبیق یابد، تمام فایل‌ها و زیردایرکتوری‌ها نیز به صورت بازگشتی تطبیق می‌یابند.
.RE
.IP ""
الگوهای مسیر ممکن است شامل نویسه‌های کنترلی '*' و '?' باشند. الگوهای نسبی (مانند ‎*.mp3‎) با نام فایل در هر دایرکتوری مطابقت دارند. الگوهای مطلق (مانند ‎/dir/file‎)، به عنوان مسیرهایی در نظر گرفته می‌شوند که از دایرکتوری اصلی در حال ضبط، یا ریشه حجم NTFS در حالت ضبط حجم NTFS شروع می‌شوند. از حروف درایو در مسیرها استفاده نکنید؛ آن‌ها نادیده گرفته خواهند شد. جداکننده‌های مسیر می‌توانند اسلش رو به جلو یا اسلش رو به عقب باشند.
.IP ""
خطوطی که با نویسه‌های '#' یا ';' شروع می‌شوند به عنوان توضیح (comment) در نظر گرفته شده و نادیده گرفته می‌شوند. الگوهای دارای فاصله خالی نیازی به قرار گرفتن در گیومه ندارند؛ با این حال، در صورت استفاده، هر دو نوع گیومه تکی و دوتایی پذیرفته می‌شوند.
.IP ""
اگر این گزینه مشخص نشود، فایل پیکربندی پیش‌فرض زیر استفاده می‌شود:
.IP ""
.RS
.RS
.nf
[ExclusionList]
\\$ntfs.log
\\hiberfil.sys
\\pagefile.sys
\\swapfile.sys
\\System Volume Information
\\RECYCLER
\\$RECYCLE.BIN
\\$Recycle.Bin
\\Windows\\CSC
.RE
.RE
.fi
.IP ""
با این حال، در صورتی که \fB--wimboot\fR نیز مشخص شده باشد، رفتار ویژه‌ای اعمال می‌شود. به‌طور پیش‌فرض با مشخص شدن \fB--wimboot\fR، فایل Windows/System32/WimBootCompress.ini در دایرکتوری در حال ضبط به عنوان فایل پیکربندی استفاده خواهد شد. با این حال، این را می‌توان با استفاده از \fB--config\fR بازنویسی کرد؛ و این کار همچنین باعث می‌شود فایل پیکربندی مشخص‌شده در ایمیج WIM به عنوان Windows/System32/WimBootCompress.ini ذخیره شود و هر فایل موجود در فایل‌سیستم را بازنویسی کند.
.TP
\fB--unix-data\fR
(فقط در سیستم‌های شبه‌یونیکس) متادیتای اختصاصی یونیکس و فایل‌های ویژه را ذخیره می‌کند. این شامل موارد زیر است: مجوزهای استاندارد فایل یونیکس (مالک، گروه و حالت دسترسی)؛ گره‌های دستگاه، پایپ‌های نام‌گذاری‌شده و سوکت‌ها؛ و ویژگی‌های گسترش‌یافته (فقط در لینوکس). این اطلاعات بعداً می‌تواند توسط \fBwimapply\fR با گزینه \fB--unix-data\fR بازیابی شود.
.IP
اطلاعات اختصاصی یونیکس توسط نرم‌افزارهای WIM مایکروسافت و توسط نسخه ویندوز wimlib نادیده گرفته می‌شوند.
.TP
\fB--no-acls\fR
عدم ضبط توصیف‌کننده‌های امنیت (security descriptors) فایل‌ها.
.TP
\fB--strict-acls\fR
در صورتی که توصیف‌کننده امنیت کامل هر فایلی قابل خواندن نباشد، بلافاصله با خطا متوقف می‌شود. در ویندوز، رفتار پیش‌فرض بدون این گزینه این است که ابتدا تلاش می‌شود SACL از توصیف‌کننده امنیت حذف شود، سپس تلاش می‌شود توصیف‌کننده امنیت به طور کامل حذف گردد. هدف از این کار ضبط بیشترین داده ممکن بدون نیاز همیشگی به مجوزهای Administrator است. با این حال، اگر مایلید همه توصیف‌کننده‌های امنیت دقیقاً ضبط شوند، ممکن است بخواهید این گزینه را ارائه دهید، هرچند که کاربر Administrator در هر صورت باید مجوز خواندن همه چیز را داشته باشد.
.TP
\fB--rpfix\fR, \fB--norpfix\fR
تنظیم اینکه آیا مقصدهای پیوندهای نمادین مطلق (در اصطلاح ویندوز: نقاط بازپارس) اصلاح شوند یا خیر. هنگامی که فعال باشد (\fB--rpfix\fR)، پیوندهای نمادین مطلقی که به داخل درخت دایرکتوری در حال ضبط اشاره می‌کنند، به گونه‌ای اصلاح خواهند شد که نسبت به ریشه درخت دایرکتوری در حال ضبط مطلق باشند. هنگامی که غیرفعال باشد (\fB--norpfix\fR)، پیوندهای نمادین مطلق دقیقاً به همان شکلی که هستند ضبط خواهند شد.
.IP ""
رفتار پیش‌فرض \fBwimcapture\fR معادل \fB--rpfix\fR است. رفتار پیش‌فرض \fBwimappend\fR در صورتی که اصلاحات نقاط بازپارس پیش‌تر روی \fIWIMFILE\fR انجام شده باشد معادل \fB--rpfix\fR است، در غیر این صورت معادل \fB--norpfix\fR خواهد بود.
.IP ""
در مورد ضبط از چند منبع (مشخص شدن \fB--source-list\fR)، ارسال \fB--norpfix\fR توصیه می‌شود. در غیر این صورت، اصلاح نقاط بازپارس در تمام منابع ضبط که مقصدشان مکان‌های غیرریشه در ایمیج WIM است غیرفعال می‌شود، در حالی که منابع ضبط که مقصدشان ریشه WIM است رفتار پیش‌فرض پاراگراف قبل را دریافت می‌کنند.
.TP
\fB--source-list\fR
\fBwimcapture\fR و \fBwimappend\fR از ایجاد ایمیج WIM از چندین فایل یا دایرکتوری مجزا پشتیبانی می‌کنند. هنگامی که \fB--source-list\fR مشخص شود، آرگومان \fISOURCE\fR نام یک فایل متنی را تعیین می‌کند که هر خط آن ۱ یا ۲ مسیر فایل جداشده با فاصله خالی است. نخستین مسیر فایل، یعنی منبع، مسیر فایل یا دایرکتوری را برای ضبط در ایمیج WIM مشخص می‌کند. این مسیر می‌تواند مطلق یا نسبت به دایرکتوری کاری فعلی باشد. دومین مسیر فایل، در صورت ارائه، مقصد است و مسیری را در ایمیج WIM مشخص می‌کند که این فایل یا دایرکتوری تحت آن ذخیره خواهد شد. اسلش‌های ابتدا و انتهای مقصد نادیده گرفته می‌شوند، مگر اینکه کاملاً از اسلش تشکیل شده باشد (مانند "/")، که نشان می‌دهد دایرکتوری قرار است به ریشه ایمیج WIM تبدیل شود. در صورت حذف، رشته مقصد به صورت پیش‌فرض همان رشته منبع خواهد بود.
.IP ""
نمونه‌ای از یک فایل فهرست منبع به شرح زیر است:
.IP ""
.RS
.RS
.nf
# ساخت ایمیج WIM از دایرکتوری 'winpe'
winpe	/

# ارسال دایرکتوری 'overlay' به '/overlay' در ایمیج WIM
overlay	/overlay

# همپوشانی یک دایرکتوری مجزا مستقیماً روی ریشه ایمیج WIM
/data/stuff	/
.RE
.RE
.fi
.IP ""
زیردایرکتوری‌ها در WIM بر حسب نیاز ایجاد می‌شوند. چندین دایرکتوری منبع ممکن است مقصد مشترکی داشته باشند که به معنای همپوشانی (overlay) است. در صورتی که این امر منجر به اضافه شدن چندباره یک فایل غیردایرکتوری به ایمیج WIM شود، آخرین نسخه (همان‌طور که در فایل فهرست منبع لیست شده است) بر نسخه‌های قبلی ارجحیت دارد.
.IP ""
مسیرهای فایلی که شامل فاصله خالی هستند می‌توانند درون گیومه تکی یا دوتایی قرار گیرند. گیومه‌ها نباید اسکیپ شوند.
.IP ""
خطوطی که فقط از فاصله خالی تشکیل شده‌اند و خطوطی که با '#' با فاصله‌های خالی اختیاری پیش از آن شروع می‌شوند، نادیده گرفته می‌شوند.
.IP ""
به عنوان یک حالت ویژه، اگر \fISOURCE\fR به صورت "-" باشد، فهرست منبع به جای یک فایل خارجی از ورودی استاندارد خوانده می‌شود.
.IP ""
حالت ضبط حجم NTFS در سیستم‌های شبه‌یونیکس را نمی‌توان با \fB--source-list\fR استفاده کرد، زیرا فقط ضبط یک حجم کامل NTFS پشتیبانی می‌شود.
.TP
\fB--pipable\fR
در \fBwimcapture\fR، یک WIM «پایپ‌پذیر» اختصاصی wimlib ایجاد می‌کند که می‌تواند به طور کاملاً ترتیبی ضبط و اعمال شود. اگر \fIWIMFILE\fR به صورت "-" مشخص شده باشد، WIM پایپ‌پذیر مستقیماً در خروجی استاندارد نوشته می‌شود؛ در غیر این صورت، طبق معمول روی دیسک نوشته می‌شود. ایمیج موجود در WIM پایپ‌پذیر را می‌توان بعداً با \fBwimapply\fR، چه از روی دیسک و چه از ورودی استاندارد اعمال کرد. یک کاربرد متداول WIMهای پایپ‌پذیر ممکن است شامل استریم کردن ایمیج WIM به یک سرور راه دور هنگام ضبط آن، و/یا استریم کردن ایمیج WIM از یک سرور راه دور هنگام اعمال آن باشد.
.IP ""
به طور کلی، تمام دستورهای \fBwimlib-imagex\fR روی هر دو نوع WIMهای پایپ‌پذیر و غیرپایپ‌پذیر کار می‌کنند. همچنین می‌توان از \fBwimoptimize\fR و \fBwimexport\fR برای تبدیل بین WIMهای پایپ‌پذیر و غیرپایپ‌پذیر استفاده کرد. با این حال، چند محدودیت برای WIMهای پایپ‌پذیر وجود دارد:
.RS
.IP \[bu] 4
WIMهای پایپ‌پذیر یک افزونه wimlib هستند که با نرم‌افزارهای WIM مایکروسافت یا برنامه‌های دیگر مانند 7-Zip سازگار \fIنیستند\fR.
.IP \[bu]
با استفاده از \fBwimappend\fR، می‌توان چندین ایمیج را به یک WIM پایپ‌پذیر اضافه کرد. این کار پشتیبانی می‌شود، هرچند کارایی آن نسبت به WIMهای غیرپایپ‌پذیر کمتر است زیرا یک WIM پایپ‌پذیر در هر بار الحاق به آن به طور کامل بازسازی می‌شود؛ و هنگام پایپ کردن چنین WIMی به \fBwimapply\fR برای استخراج یک ایمیج، مقداری داده غیرضروری از طریق پایپ ارسال خواهد شد.
.IP \[bu]
اگرچه یک ایمیج WIM پایپ‌پذیر می‌تواند با استفاده از \fBwimupdate\fR به‌روزرسانی شود، اما این کار نیازمند بازسازی کامل فایل WIM است و آن را نسبت به به‌روزرسانی یک WIM غیرپایپ‌پذیر کم‌بازده‌تر می‌کند.
.IP \[bu]
WIMهای پایپ‌پذیر یکپارچه (solid) هنوز پشتیبانی نمی‌شوند.
.RE
.TP
\fB--not-pipable\fR
در \fBwimappend\fR، فایل WIM را در قالب غیرپایپ‌پذیر (عادی) بازسازی می‌کند. این گزینه فقط در صورتی مفید است که بخواهید ایمیجی را به یک WIM پایپ‌پذیر اضافه کنید (گزینه \fB--pipable\fR را ببینید) که می‌خواهید به جای آن در قالب غیرپایپ‌پذیر باشد. توجه داشته باشید که از \fBwimoptimize\fR(1) نیز می‌توان برای تبدیل بین WIMهای غیرپایپ‌پذیر و پایپ‌پذیر استفاده کرد.
.TP
\fB--update-of\fR=[\fIWIMFILE\fR:]\fIIMAGE\fR
اشاره می‌کند به اینکه ایمیج در حال ضبط یا الحاق از \fISOURCE\fR عمدتاً همان ایمیج موجود \fIIMAGE\fR در \fIWIMFILE\fR است، اما در زمان دیرتری ضبط شده و احتمالاً در این فاصله زمانی تغییراتی داشته است. این قابلیت برای استفاده در پشتیبان‌گیری‌های افزایشی از همان فایل‌سیستم یا درخت دایرکتوری طراحی شده است. \fIIMAGE\fR می‌تواند یک ایندکس مبتنی بر ۱ یا نام یک ایمیج موجود در \fIWIMFILE\fR باشد. همچنین می‌تواند یک عدد صحیح منفی باشد تا ایندکس‌گذاری معکوس در ایمیج‌ها انجام شود (مثلاً ۱- به معنای آخرین ایمیج موجود در \fIWIMFILE\fR است).
.IP ""
هنگامی که این گزینه ارائه شود، ضبط یا الحاق ایمیج جدید با نخواندن فایل‌هایی که بر اساس متادیتایی مانند مهرهای زمانی به نظر می‌رسد از زمان بایگانی در \fIIMAGE\fR موجود تغییر نکرده‌اند، بهینه‌سازی می‌شود. به استثنای دستکاری مهرهای زمانی، این گزینه فقط بر عملکرد تأثیر می‌گذارد و ایمیج WIM حاصل را تغییر نمی‌دهد (اما یادداشت زیر را ببینید).
.IP ""
همان‌طور که نشان داده شده است، ساختار دستوری کامل برای آرگومان این گزینه تعیین فایل WIM، دونقطه و ایمیج است؛ برای مثال، "--update-of mywim.wim:1". با این حال، اگر \fB--delta-from\fR دقیقاً یک بار مشخص شده باشد، فایل WIM و دونقطه می‌توانند حذف شوند، که در این صورت WIM به طور پیش‌فرض همان مشخص‌شده در \fB--delta-from\fR خواهد بود؛ یا اگر عملیات \fBwimappend\fR باشد نه \fBwimcapture\fR، در این صورت WIM به طور پیش‌فرض همان فایلی خواهد بود که به آن الحاق می‌شود.
.IP ""
نکته: در نسخه ویندوز wimlib، مشاهده شده است که حالت \fB--update-of\fR در تشخیص تغییرات در محتویات فایل کاملاً قابل اعتماد نیست و گاهی اوقات باعث می‌شود محتویات قدیمی چند فایل به جای محتویات فعلی بایگانی شوند. علت این مشکل این است که ویندوز بلافاصله پس از هر بار نوشتن در یک فایل، مهر زمانی آخرین تغییر آن را به‌روزرسانی نمی‌کند. متأسفانه، هیچ روش شناخته‌شده‌ای برای برنامه‌هایی مانند wimlib وجود ندارد که این باگ را به طور خودکار دور بزنند. دور زدن‌های دستی امکان‌پذیر است؛ از نظر تئوری، انجام هر عملی که باعث بسته شدن فایل‌های مشکل‌ساز شود، مانند راه‌اندازی مجدد برنامه‌ها یا خود رایانه، باید باعث به‌روزرسانی مهرهای زمانی آخرین تغییر فایل‌ها شود. همچنین توجه داشته باشید که wimlib در تعیین اینکه آیا یک فایل تغییر کرده است یا خیر، اندازه فایل‌ها و همچنین مهرهای زمانی را مقایسه می‌کند، که به کاهش احتمال بروز این مشکل کمک می‌نماید؛ و این مشکل در سایر سیستم‌های عامل مانند لینوکس که مهرهای زمانی آخرین تغییر فایل‌ها را به درستی نگهداری می‌کنند رخ نمی‌دهد.
.TP
\fB--delta-from\fR=\fIWIMFILE\fR
ضبط یا الحاق ایمیج جدید به عنوان یک "دلتا" (تغییرات) نسبت به \fIWIMFILE\fR. هر داده فایلی که معمولاً نیاز به بایگانی در WIM جدید یا به‌روزرسانی‌شده دارد، اگر از قبل در \fIWIMFILE\fR که دلتا بر پایه آن است وجود داشته باشد، حذف می‌شود. WIM حاصل همچنان حاوی یک کپی کامل از متادیتای ایمیج خواهد بود، اما این متادیتا معمولاً تنها بخش کوچکی از حجم کل یک WIM است.
.IP ""
این گزینه می‌تواند چندین بار مشخص شود، که در این صورت دلتا WIM حاصل فقط شامل داده‌های فایلی خواهد بود که در هیچ یک از WIMهای پایه مشخص‌شده وجود نداشته باشند.
.IP ""
برای کار بر روی دلتا WIM حاصل با استفاده از سایر دستورها مانند \fBwimapply\fR، باید دلتا WIM را به عنوان فایل WIM برای عملیات مشخص کنید، اما همچنین باید با استفاده از گزینه \fB--ref\fR به WIM(های) پایه ارجاع دهید. هشدار: برای حفظ عملکرد صحیح دلتا WIM، پس از ضبط دلتا از WIM(های) پایه، فقط می‌توانید فایل‌ها و ایمیج‌هایی را به WIM(های) پایه اضافه کنید، نه اینکه حذف نمایید.
.IP ""
گزینه \fB--delta-from\fR می‌تواند با \fB--update-of\fR ترکیب شود تا سرعت ضبط یک دلتا WIM افزایش یابد.
.IP ""
به عنوان مثال، توالی پشتیبان‌گیری و بازیابی زیر را در نظر بگیرید:
.IP ""
.RS
.nf
# پشتیبان‌گیری اولیه

$ wimcapture /some/directory bkup-base.wim

# چند روز بعد، ایجاد دومین پشتیبان به عنوان دلتا از اولین پشتیبان

$ 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
.RE
.fi
.IP ""
با این حال، توجه داشته باشید که به عنوان جایگزینی برای توالی بالا که از یک دلتا WIM استفاده می‌کرد، نسخه پشتیبان دوم می‌توانست به سادگی با استفاده از \fBwimappend\fR به عنوان ایمیج جدید به WIM الصاق شود. دلتا WIMها فقط باید در صورتی استفاده شوند که بخواهید پشتیبان‌ها یا ایمیج‌ها را بر پایه یک فایل مجزا و بزرگ که به ندرت تغییر می‌کند پایه‌گذاری کنید.
.IP ""
گزینه \fB--delta-from\fR توسط هر دو دستور \fBwimcapture\fR و \fBwimappend\fR پشتیبانی می‌شود.
.IP ""
دلتا WIMها با نرم‌افزارهای WIM مایکروسافت سازگار هستند. برای مثال، می‌توانید از گزینه /ref در ImageX برای ارجاع به WIM(های) پایه، مشابه بالا استفاده کنید.
.IP ""
نکته اضافی: wimlib به اندازه کافی تعمیم‌یافته است به طوری که می‌توانید در واقع \fB--pipable\fR و \fB--delta-from\fR را با هم ترکیب کنید تا دلتا WIMهای پایپ‌پذیر بسازید. در چنین مواردی، WIM(های) پایه نیز باید مانند دلتا WIM به صورت پایپ‌پذیر ضبط شوند، و هنگام اعمال ایمیج، WIM(های) پایه باید پس از دلتا WIM از طریق پایپ ارسال شوند.
.TP
\fB--wimboot\fR
ایمیج را به عنوان سازگار با WIMBoot علامت‌گذاری می‌کند. برای اطلاعات بیشتر در مورد WIMBoot به مستندات مایکروسافت مراجعه کنید. با \fBwimcapture\fR این گزینه نوع فشرده‌سازی را روی XPRESS و اندازه تکه را روی ۴۰۹۶ بایت تنظیم می‌کند؛ با این حال، این مقادیر همچنان می‌توانند به ترتیب از طریق پارامترهای \fB--compress\fR و \fB--chunk-size\fR بازنویسی شوند. علاوه بر این، این گزینه در صورت وجود و دسترسی، فایل پیکربندی را روی \fISOURCE\fR\\Windows\\System32\\WimBootCompress.ini تنظیم می‌کند؛ با این حال، این مورد نیز ممکن است از طریق پارامتر \fB--config\fR بازنویسی شود.
.TP
\fB--unsafe-compact\fR
با \fBwimappend\fR، بایگانی WIM را درجا فشرده (compact) کرده و داده‌های جدید را الحاق می‌کند و "حفره‌ها" را از بین می‌برد. این روش کارآمد است، اما به طور کلی این گزینه \fIنباید\fR استفاده شود زیرا فشرده‌سازی ناموفق یا متوقف‌شده باعث خراب شدن بایگانی WIM می‌شود. برای اطلاعات بیشتر، مستندات مربوط به این گزینه را در \fBwimoptimize\fR(1) ببینید.
.TP
\fB--snapshot\fR
یک تصویر لحظه‌ای (snapshot) موقت از سیستم فایل دایرکتوری منبع ایجاد کرده و فایل‌ها را از آن ضبط می‌کند. در حال حاضر، این گزینه فقط در ویندوز پشتیبانی می‌شود، جایی که از Volume Shadow Copy Service (VSS) استفاده می‌کند. با استفاده از این گزینه، می‌توانید یک پشتیبان منسجم از حجم سیستم یک ویندوز در حال اجرا ایجاد کنید بدون اینکه با مشکلات فایل‌های قفل‌شده مواجه شوید. برای اینکه اسنپ‌شات VSS با موفقیت ایجاد شود، \fBwimlib-imagex\fR باید با دسترسی Administrator اجرا شود و نمی‌تواند در حالت WoW64 اجرا گردد (یعنی اگر ویندوز ۶۴ بیتی است، \fBwimlib-imagex\fR نیز باید ۶۴ بیتی باشد).
.TP
\fB--create\fR
با \fBwimappend\fR، اگر فایل WIM هنوز وجود نداشته باشد، آن را ایجاد می‌کند (مانند \fBwimcapture\fR).
.SH "نکات (NOTES)"
دستور \fBwimappend\fR از الصاق یک ایمیج به یک WIM تکه‌تکه‌شده (split WIM) پشتیبانی نمی‌کند.
.PP
به جز زمان استفاده از \fB--unsafe-compact\fR، سقط کردن دستور \fBwimappend\fR در میانه راه بی‌خطر است؛ با این حال، پس از انجام این کار، توصیه می‌شود \fBwimoptimize\fR را اجرا کنید تا هر داده‌ای که به فایل فیزیکی WIM الحاق شده اما هنوز در ساختار WIM گنجانده نشده است حذف شود، مگر اینکه WIM در حال بازسازی کامل بوده باشد (مثلاً با \fB--rebuild\fR)، که در این صورت باید فایل موقت باقی‌مانده را حذف کنید.
.PP
ابزار \fBwimlib-imagex\fR فایل‌های WIM سازگار با نرم‌افزارهای مایکروسافت (WIMGAPI, ImageX, DISM) ایجاد می‌کند، با برخی ملاحظات:
.IP \[bu] 4
با \fBwimlib-imagex\fR در سیستم‌های شبه‌یونیکس، امکان ایجاد یک ایمیج WIM حاوی فایل‌هایی با نام‌هایی که فقط در بزرگی و کوچکی حروف تفاوت دارند، یا فایل‌هایی با نام‌های حاوی نویسه‌های ':', '*', '?', '"', '<', '>', '|' یا '\\' وجود دارد که در فایل‌سیستم‌های منطبق بر POSIX معتبر هستند اما در ویندوز معتبر نیستند. هشدار داده می‌شود که چنین فایل‌هایی به‌طور پیش‌فرض توسط نسخه ویندوز \fBwimlib-imagex\fR استخراج نخواهند شد، و (حتی بدتر) ابزار ImageX مایکروسافت ممکن است با چنین نام‌هایی دچار سردرگمی شده و استخراج ایمیج را در میانه راه متوقف کند.
.IP \[bu]
فایل‌های WIM پایپ‌پذیر با نرم‌افزارهای مایکروسافت ناسازگار هستند. WIMهای پایپ‌پذیر فقط در صورتی ایجاد می‌شوند که \fIWIMFILE\fR به صورت "-" (خروجی استاندارد) مشخص شده باشد یا پرچم \fB--pipable\fR تعیین شده باشد.
.IP \[bu]
فایل‌های WIM ضبط‌شده با اندازه تکه غیرپیش‌فرض (با گزینه \fB--chunk-size\fR) یا به عنوان بایگانی‌های یکپارچه (با گزینه \fB--solid\fR) یا با فشرده‌سازی LZMS (با \fB--compress\fR=LZMS یا \fB--compress\fR=recovery) سطوح متفاوتی از سازگاری با نرم‌افزارهای مایکروسافت دارند. به طور کلی، نسخه‌های جدیدتر نرم‌افزارهای مایکروسافت سازگاری بیشتری دارند.
.SH "مثال‌ها (EXAMPLES)"
مثال اول: ایجاد یک WIM جدید به نام 'mywim.wim' با فشرده‌سازی LZX (یا "maximum") که حاوی یک ایمیج ضبط‌شده از درخت دایرکتوری 'somedir' خواهد بود. توجه داشته باشید که نام ایمیج نیازی به مشخص شدن ندارد و به طور پیش‌فرض 'somedir' خواهد بود:
.RS
.PP
wimcapture somedir mywim.wim
.RE
.PP
سپس، الحاق ایمیج یک درخت دایرکتوری دیگر به WIM ایجادشده در بالا:
.RS
.PP
wimappend anotherdir mywim.wim
.RE
.PP
بسیار ساده، و مثال‌های بالا از ایجاد ایمیج از درخت‌های دایرکتوری هم در سیستم‌های شبه‌یونیکس و هم در ویندوز کار می‌کنند. سپس، ضبط یک WIM با چندین گزینه غیرپیش‌فرض، از جمله فشرده‌سازی XPRESS (یا "fast")، اطلاعات یکپارچگی اضافی، عدم دستکاری پیوندهای نمادین مطلق، و یک نام و توضیح برای ایمیج:
.RS
.PP
wimcapture somedir mywim.wim --compress=fast \\
.RS
--check --norpfix "Some Name" "Some Description"
.RE
.RE
.PP
در یک سیستم شبه‌یونیکس، یک حجم کامل NTFS را با استفاده از حالت \fBضبط حجم NTFS در یونیکس (NTFS VOLUME CAPTURE - UNIX)\fR در یک WIM جدید ضبط کرده و نام ایمیج را "Windows 7" بگذارید:
.RS
.PP
wimcapture /dev/sda2 windows7.wim "Windows 7"
.RE
.PP
یا در ویندوز، برای ضبط یک حجم کامل NTFS باید در عوض دایرکتوری ریشه حجم سوارشده را مشخص کنید، برای مثال:
.RS
.PP
wimcapture E:\\ windows7.wim "Windows 7"
.RE
.PP
مشابه مثال یونیکس در بالا، اما ضبط WIM در قالب "پایپ‌پذیر" اختصاصی wimlib که می‌تواند به \fBwimapply\fR پایپ شود:
.RS
.PP
wimcapture /dev/sda2 windows7.wim "Windows 7" --pipable
.RE
.PP
مشابه بالا، اما به جای نوشتن WIM پایپ‌پذیر در فایل "windows7.wim"، آن را مستقیماً در خروجی استاندارد از طریق یک پایپ به برنامه دیگری به نام "someprog" بنویسید، که می‌تواند برای مثال برنامه‌ای یا اسکریپتی باشد که داده‌ها را به یک سرور استریم می‌کند:
.RS
.PP
wimcapture /dev/sda2 - "Windows 7" | someprog
.RE
.SH "همچنین ببینید (SEE ALSO)"
.BR wimlib-imagex (1),
.BR wimapply (1),
.BR wimoptimize (1)