نام (NAME)

wimcapture, wimappend - ضبط یا الصاق یک ایمیج WIM

خلاصه دستور (SYNOPSIS)

wimcapture SOURCE WIMFILE [IMAGE_NAME  [IMAGE_DESC]] [OPTION...]
wimappend SOURCE WIMFILE [IMAGE_NAME  [IMAGE_DESC]] [OPTION...]

توضیحات (DESCRIPTION)

دستورهای wimcapture (معادل: wimlib-imagex capture) و wimappend (معادل: wimlib-imagex append) یک ایمیج جدید Windows Imaging (WIM) ایجاد (یا «ضبط») می‌کنند. wimcapture یک بایگانی WIM جدید در WIMFILE برای نگهداری ایمیج جدید ایجاد می‌کند، در حالی که wimappend ایمیج را به بایگانی WIM موجود WIMFILE اضافه می‌کند (یا با گزینه --create، در صورت نیاز آن را ایجاد می‌نماید).

پارامتر SOURCE مکان فایل‌هایی را که قرار است ایمیج WIM از آن‌ها ساخته شود مشخص می‌کند. اگر SOURCE یک دایرکتوری یا پیوند نمادین اشاره‌کننده به یک دایرکتوری باشد، ایمیج مطابق با ضبط دایرکتوری در یونیکس (DIRECTORY CAPTURE - UNIX) یا ضبط دایرکتوری در ویندوز (DIRECTORY CAPTURE - WINDOWS) از آن دایرکتوری ضبط می‌شود. همچنین اگر گزینه --source-list مشخص شده باشد، SOURCE به عنوان فایلی حاوی فهرستی از فایل‌ها و دایرکتوری‌ها برای گنجاندن در ایمیج تفسیر می‌گردد. علاوه بر این، اگر SOURCE یک دستگاه بلوکی یونیکس باشد، ایمیج از حجم NTFS موجود روی آن مطابق با ضبط حجم NTFS در یونیکس (NTFS VOLUME CAPTURE - UNIX) ضبط می‌شود.

پارامترهای IMAGE_NAME و IMAGE_DESC نام و توضیحات اختصاص‌یافته به ایمیج جدید را مشخص می‌کنند. اگر IMAGE_NAME تعیین نشود، به‌طور پیش‌فرض از بخش نام فایل SOURCE استفاده می‌شود و در صورت لزوم یک پسوند یکتا به آن اضافه می‌گردد. در غیر این صورت، IMAGE_NAME باید نامی باشد که قبلاً توسط ایمیجی در WIMFILE استفاده نشده است، یا یک رشته خالی برای ایجاد یک ایمیج بدون نام باشد. اگر IMAGE_DESC مشخص نشود، هیچ توضیحی به ایمیج جدید داده نخواهد شد.

اگر WIMFILE به صورت "-" مشخص شود، گزینه --pipable فرض شده و یک WIM پایپ‌پذیر در خروجی استاندارد نوشته می‌شود (این یک قابلیت افزوده wimlib است).

ضبط دایرکتوری در یونیکس (DIRECTORY CAPTURE - UNIX)

در سیستم‌های شبه‌یونیکس، اگر SOURCE یک دایرکتوری یا یک پیوند نمادین به یک دایرکتوری را مشخص کند، ایمیج WIM از آن دایرکتوری ضبط خواهد شد. دایرکتوری می‌تواند روی هر نوع فایل‌سیستمی قرار داشته باشد و از نقاط اتصال (mountpoints) نیز پیروی می‌شود. در این حالت، انواع اطلاعات زیر ضبط می‌شوند:

•

دایرکتوری‌ها و فایل‌های معمولی، و محتویات فایل‌های معمولی

•

پیوندهای سخت (Hard links)

•

پیوندهای نمادین (بدون افت کیفیت به نقاط بازپارس یا Reparse Points ویندوز ترجمه می‌شوند)

•

زمان‌های آخرین تغییر (mtime) و آخرین دسترسی (atime) با دقت ۱۰۰ نانوثانیه

•

فایل‌هایی که به نظر خلوت (sparse) می‌رسند به همین عنوان علامت‌گذاری می‌شوند، اما داده‌های کامل آن‌ها همچنان ذخیره خواهد شد و مشمول فشرده‌سازی معمول قرار می‌گیرد.

•

با گزینه --unix-data: مجوزهای استاندارد فایل یونیکس (مالک، گروه و حالت دسترسی)

•

با گزینه --unix-data: گره‌های دستگاه (device nodes)، پایپ‌های نام‌گذاری‌شده (named pipes) و سوکت‌ها

•

با گزینه --unix-data: ویژگی‌های گسترش‌یافته (extended attributes ‏- فقط در لینوکس)

هیچ پشتیبانی برای ذخیره زمان‌های آخرین تغییر وضعیت (ctime) یا اطلاعات پیوند سخت برای پیوندهای نمادین وجود ندارد (هر پیوند نمادین به عنوان یک فایل مجزا ذخیره می‌شود). همچنین، نام فایل‌ها و مقصدهای پیوند نمادین که به شکل UTF-8 معتبر همراه با کدهای جایگزین (surrogate codepoints) نباشند پشتیبانی نمی‌شوند. توجه داشته باشید که اگر فایل‌سیستمی حاوی نام فایل‌ها با رمزگذاری چندبایتی دیگری مانند ISO-8859-1 دارید و می‌خواهید آن را با wimlib بایگانی کنید، ممکن است بتوانید آن را با گزینه‌ای سوار (mount) کنید که باعث شود نام فایل‌های آن به صورت UTF-8 نمایش داده شوند.

ضبط حجم NTFS در یونیکس (NTFS VOLUME CAPTURE - UNIX)

در سیستم‌های شبه‌یونیکس، SOURCE همچنین می‌تواند به عنوان یک دستگاه بلوکی (مانند /dev/sda3) حاوی یک حجم NTFS سوارنشده مشخص شود. در این حالت، wimcapture از libntfs-3g برای ضبط یک ایمیج WIM از دایرکتوری ریشه حجم NTFS استفاده می‌کند. در این حالت، تا حد امکان داده‌ها و متادیتاها ضبط می‌شوند، از جمله متادیتای اختصاصی NTFS و ویندوز:

•

تمام جریان‌های داده (data streams) تمام فایل‌های رمزگذاری‌نشده، از جمله جریان داده بدون نام و همچنین تمام جریان‌های داده نام‌گذاری‌شده.

•

نقاط بازپارس (Reparse points). برای جزئیات به بخش نقاط بازپارس و پیوندهای نمادین (REPARSE POINTS AND SYMLINKS) مراجعه کنید.

•

مهر زمانی (timestamp) ایجاد، دسترسی و تغییر فایل و دایرکتوری، با استفاده از تفکیک‌پذیری بومی NTFS با دقت ۱۰۰ نانوثانیه.

•

توصیف‌کننده‌های امنیت ویندوز (Windows security descriptors)، شامل تمام اجزا (مالک، گروه، DACL و SACL).

•

فلگ‌های ویژگی فایل DOS/ویندوز.

•

تمام نام‌های همه فایل‌ها، از جمله نام‌ها در فضای نام Win32، فضای نام DOS، فضای نام Win32+DOS و فضای نام POSIX. این شامل پیوندهای سخت نیز می‌شود.

•

شناسه‌های شیء (Object IDs).

با این حال، محدودیت‌های اصلی این حالت عبارتند از:

•

فایل‌های رمزگذاری‌شده مستثنی هستند.

•

ویژگی‌های گسترش‌یافته (EAs) هنوز ذخیره نمی‌شوند.

•

فایل‌های خلوت (sparse files) به همین عنوان علامت‌گذاری می‌شوند، اما داده‌های کامل آن‌ها همچنان با اعمال فشرده‌سازی معمول ذخیره خواهد شد.

•

برخی از انواع نقاط بازپارس به صورت شفاف توسط ویندوز ارجاع‌زدایی می‌شوند اما توسط NTFS-3G ارجاع‌زدایی نمی‌شوند. بخش نقاط بازپارس و پیوندهای نمادین (REPARSE POINTS AND SYMLINKS) را ببینید.

توجه داشته باشید که این حالت مستقیماً از libntfs-3g استفاده می‌کند، بدون اینکه از درایور ntfs-3g(8) عبور کند. بنابراین، هیچ پشتیبانی ویژه‌ای برای ضبط ایمیج WIM از دایرکتوری‌ای که یک فایل‌سیستم NTFS با استفاده از ntfs-3g(8) روی آن سوار شده است وجود ندارد؛ ابتدا باید آن را پیاده (unmount) کنید. همچنین هیچ پشتیبانی برای ضبط یک زیردایرکتوری از حجم NTFS وجود ندارد؛ شما فقط می‌توانید کل حجم را ضبط کنید.

ضبط دایرکتوری در ویندوز (DIRECTORY CAPTURE - WINDOWS)

در ویندوز، wimcapture و wimappend به صورت بومی از داده‌های اختصاصی ویندوز و NTFS پشتیبانی می‌کنند. بنابراین عملکرد آن‌ها مشابه دستورهای متناظر ImageX یا DISM مایکروسافت است. برای بهترین نتایج، دایرکتوری ضبط‌شده باید روی یک حجم NTFS باشد و برنامه با دسترسی مدیر سیستم (Administrator) اجرا شود؛ با این حال، فایل‌سیستم‌های غیر NTFS و اجرا بدون دسترسی Administrator نیز با وجود برخی محدودیت‌ها پشتیبانی می‌شوند.

در ویندوز، wimcapture و wimappend تلاش می‌کنند تا حد امکان داده‌ها و متادیتاها را ضبط نمایند، از جمله:

•

تمام جریان‌های داده (data streams) تمام فایل‌ها.

•

نقاط بازپارس (Reparse points)، در صورت پشتیبانی توسط فایل‌سیستم منبع. برای جزئیات به بخش نقاط بازپارس و پیوندهای نمادین (REPARSE POINTS AND SYMLINKS) مراجعه کنید.

•

مهرهای زمانی ایجاد، دسترسی و تغییر فایل و دایرکتوری. این موارد با تفکیک‌پذیری بومی مهر زمانی ویندوز یعنی ۱۰۰ نانوثانیه ذخیره می‌شوند.

•

توصیف‌کننده‌های امنیت (Security descriptors)، در صورت پشتیبانی توسط فایل‌سیستم منبع و عدم مشخص شدن گزینه --no-acls. نکته: هنگام اجرا بدون دسترسی Administrator، توصیف‌کننده‌های امنیت ممکن است فقط به صورت جزئی ضبط شوند (گزینه --strict-acls را ببینید).

•

ویژگی‌های فایل، شامل مخفی (hidden)، خلوت (sparse)، فشرده (compressed)، رمزگذاری‌شده (encrypted) و غیره. فایل‌های رمزگذاری‌شده به صورت رمزگذاری‌شده ذخیره خواهند شد نه متن ساده. فایل‌های فشرده‌شده به صورت شفاف، به عنوان غیرفشرده خوانده می‌شوند و مشمول فشرده‌سازی خود WIM ذخیره می‌گردند. هیچ رفتار ویژه‌ای برای ذخیره فایل‌های خلوت وجود ندارد، اما به احتمال زیاد به حجم کمی فشرده می‌شوند.

•

نام‌های DOS (8.3) فایل‌ها؛ با این حال، عدم موفقیت در خواندن آن‌ها به عنوان یک وضعیت خطا در نظر گرفته نمی‌شود.

•

پیوندهای سخت، در صورت پشتیبانی توسط فایل‌سیستم منبع.

•

شناسه‌های شیء (Object IDs)، در صورت پشتیبانی توسط فایل‌سیستم منبع.

•

ویژگی‌های گسترش‌یافته (EAs)، در صورت پشتیبانی توسط فایل‌سیستم منبع.

نقاط بازپارس و پیوندهای نمادین (REPARSE POINTS AND SYMLINKS)

یک «پیوند نمادین» (یا «symlink») یک فایل ویژه است که به فایل یا دایرکتوری دیگری «اشاره می‌کند». در ویندوز، یک «نقطه بازپارس» (reparse point) تعمیمی از پیوند نمادین است که اجازه می‌دهد دسترسی به یک فایل یا دایرکتوری به شیوه‌ای پیچیده‌تر تغییر مسیر یابد. ویندوز از نقاط بازپارس برای پیاده‌سازی پیوندهای نمادین استفاده می‌کند و گاهی از آن‌ها برای قابلیت‌های متنوع دیگر نیز بهره می‌برد. معمولاً برنامه‌ها می‌توانند انتخاب کنند که آیا می‌خواهند نقاط بازپارس و پیوندهای نمادین را «ارجاع‌زدایی» (dereference) کنند یا خیر.

رفتار پیش‌فرض wimcapture این است که نقاط بازپارس و پیوندهای نمادین ارجاع‌زدایی نمی‌شوند، به این معنی که خود نقاط بازپارس یا پیوندهای نمادین در بایگانی ذخیره می‌شوند، نه فایل‌ها یا داده‌هایی که به آن‌ها اشاره می‌کنند. گزینه --dereference وجود دارد، اما در حال حاضر فقط توسط نسخه یونیکس wimcapture روی فایل‌سیستم‌های یونیکس پشتیبانی می‌شود (هنوز برای فایل‌سیستم‌های ویندوز پیاده‌سازی نشده است).

ویندوز همچنین با انواع خاصی از نقاط بازپارس به صورت ویژه رفتار می‌کند. به عنوان مثال، برنامه‌های ویندوزی که فایل‌های داده‌های تکراری‌زدوده‌شده (deduplicated)، فایل‌های مبتنی بر WIM یا فایل‌های فشرده سیستمی را می‌خوانند، همیشه داده‌های ارجاع‌زدایی‌شده را می‌بینند، حتی اگر درخواست عدم آن را داشته باشند. بنابراین، wimcapture در ویندوز این فایل‌ها را به صورت ارجاع‌زدایی‌شده ذخیره می‌کند، نه به عنوان نقاط بازپارس. اما wimcapture در یونیکس در حالت NTFS-3G نمی‌تواند این فایل‌ها را ارجاع‌زدایی کند و در عوض آن‌ها را به عنوان نقاط بازپارس ذخیره خواهد کرد. این تفاوت می‌تواند در موقعیت‌های خاصی مهم باشد، مثلاً هنگام ضبط فایل‌های deduplicated که برای خوانده شدن پس از استخراج، نیازمند وجود مخزن قطعات (chunk store) نیز هستند.

گزینه‌ها (OPTIONS)

--boot

علامت‌گذاری ایمیج جدید به عنوان ایمیج «قابل بوت» (bootable) در WIM. ایمیج «قابل بوت» ایمیجی است که بوت‌لودر ویندوز هنگام بارگذاری Windows PE از WIM از آن استفاده خواهد کرد.

--check

گنجاندن اطلاعات یکپارچگی اضافی در WIM حاصل. با wimappend، یکپارچگی WIM نیز قبل از الصاق به آن بررسی می‌شود. همچنین یکپارچگی هر WIM مشخص‌شده با --update-of و/یا --delta-from را بررسی می‌کند.

--include-integrity

گنجاندن اطلاعات یکپارچگی اضافی در WIM حاصل؛ یعنی مانند --check اما بدون انجام بررسی قبلی.

--compress=TYPE[:LEVEL]

در wimcapture، از قالب فشرده‌سازی مشخص‌شده در فایل WIM جدید استفاده می‌کند. پارامتر TYPE می‌تواند "none"، "XPRESS" (نام مستعار: "fast")، "LZX" (نام مستعار: "maximum") یا "LZMS" (نام مستعار: "recovery") باشد. حساسیت به حروف بزرگ و کوچک در TYPE وجود ندارد. حالت پیش‌فرض "LZX" است.

همچنین می‌توانید به صورت اختیاری یک LEVEL فشرده‌سازی عدد صحیح را مشخص کنید. سطح فشرده‌سازی مشخص می‌کند که الگوریتم فشرده‌سازی برای TYPE تعیین‌شده با چه شدتی برای فشرده‌سازی داده‌ها کار خواهد کرد. مقادیر به گونه‌ای مقیاس‌بندی شده‌اند که ۲۰ فشرده‌سازی سریع، ۵۰ فشرده‌سازی متوسط و ۱۰۰ فشرده‌سازی بالا است. با این حال، می‌توانید هر مقداری را انتخاب کنید و محدود به این مقادیر خاص نیستید. مقدار پیش‌فرض ۵۰ است.

این گزینه فقط بر نوع فشرده‌سازی استفاده‌شده در منابع WIM غیریکپارچه (non-solid) تأثیر می‌گذارد. اگر در حال ساخت یک WIM یکپارچه (solid) با استفاده از گزینه --solid هستید، احتمالاً در عوض به گزینه --solid-compress نیاز دارید.

اگر فشرده‌سازی LZMS را انتخاب می‌کنید، احتیاط کنید. این حالت با wimlib قبل از نسخه v1.6.0، با WIMGAPI قبل از ویندوز ۸، با DISM قبل از ویندوز ۸.۱ و با 7-Zip قبل از نسخه v15.12 سازگار نیست. همچنین توجه داشته باشید که انتخاب فشرده‌سازی LZMS به طور خودکار به معنای فشرده‌سازی حالت یکپارچه (solid) نیست، بر خلاف آنچه در DISM رخ می‌دهد. اگر می‌خواهید یک WIM یکپارچه یا "فایل ESD" ایجاد کنید، از --solid استفاده نمایید.

--chunk-size=SIZE

در wimcapture، از اندازه تکه فشرده‌سازی SIZE بایت استفاده می‌کند. اندازه تکه فشرده‌سازی بزرگتر منجر به نسبت فشرده‌سازی بهتری می‌شود. wimlib بسته به نوع فشرده‌سازی از اندازه‌های تکه مختلفی پشتیبانی می‌کند:

می‌توانید عدد کامل را وارد کنید (مانند 32768)، یا از یکی از پسوندهای K، M یا G استفاده نمایید. پسوندهای KiB، MiB و GiB نیز پذیرفته می‌شوند.

این گزینه فقط بر اندازه تکه مورد استفاده در منابع WIM غیریکپارچه تأثیر می‌گذارد. اگر در حال ایجاد یک WIM یکپارچه هستید (با استفاده از گزینه --solid)، احتمالاً در عوض به --solid-chunk-size نیاز دارید.

در صورتی که سازگاری با نرم‌افزارهای WIM مایکروسافت مد نظر است با احتیاط از این گزینه استفاده کنید، زیرا نرم‌افزارهای آن‌ها پشتیبانی محدودی از اندازه‌های تکه غیرپیش‌فرض دارند.

--solid

در wimcapture، یک فایل WIM «یکپارچه» (solid) ایجاد می‌کند که فایل‌ها را با هم فشرده می‌سازد نه به صورت مستقل. این امر منجر به نسبت فشرده‌سازی به مراتب بهتری می‌شود، اما به قیمت فشرده‌سازی کند با مصرف حافظه بسیار بالا، سازگاری کاهش‌یافته و دسترسی تصادفی کند به فایل WIM حاصل تمام می‌شود.

به‌طور پیش‌فرض این گزینه فشرده‌سازی یکپارچه LZMS را فعال می‌کند، در نتیجه فایلی معادل فایلی که با گزینه /compress:recovery در DISM ساخته شده ایجاد می‌نماید. به چنین فایل‌هایی "فایل‌های ESD" نیز گفته می‌شود و برای نخستین بار در ویندوز ۸ توسط WIMGAPI، در ویندوز ۸.۱ توسط DISM و در نسخه 15.12 توسط 7-Zip پشتیبانی شدند.

--solid-compress=TYPE[:LEVEL]

مشابه --compress، اما نوع فشرده‌سازی مورد استفاده در منابع یکپارچه (solid) را تعیین می‌کند. حالت پیش‌فرض، فشرده‌سازی LZMS است. این گزینه تنها زمانی اعمال می‌شود که --solid نیز مشخص شده باشد.

--solid-chunk-size=SIZE

مشابه --chunk-size، اما اندازه تکه مورد استفاده در منابع یکپارچه را تعیین می‌کند. مقدار پیش‌فرض، با فرض فشرده‌سازی LZMS، برابر 64MiB (67108864) است؛ این مقدار نیازمند حدود 640MiB حافظه به ازای هر ریسه (thread) است. این گزینه تنها زمانی اعمال می‌شود که --solid نیز مشخص شده باشد. نکته: نرم‌افزارهای WIM مایکروسافت با اندازه‌های تکه LZMS بزرگتر از 64MiB سازگار نیستند.

--threads=NUM_THREADS

تعداد ریسه‌ها (threads) برای استفاده در فشرده‌سازی داده‌ها. پیش‌فرض: تشخیص خودکار (تعداد پردازنده‌های در دسترس).

--rebuild

در wimappend، به جای الحاق داده‌های جدید به انتهای فایل WIM، کل فایل WIM را بازسازی می‌کند. بازسازی WIM کندتر است، اما مقداری فضا را که در غیر این صورت به عنوان یک حفره در WIM باقی می‌ماند، ذخیره می‌کند. همچنین به wimoptimize(1) مراجعه کنید.

--flags=EDITIONID

مشخص کردن یک رشته برای استفاده در عنصر <FLAGS> داده‌های XML برای ایمیج جدید.

--image-property NAME=VALUE

اختصاص یک ویژگی دلخواه به ایمیج جدید در سند XML فایل WIM. پارامتر VALUE رشته‌ای است که به عنوان مقدار ویژگی تنظیم می‌شود. NAME نام ویژگی ایمیج است، برای مثال "NAME"، "DESCRIPTION" یا "TOTALBYTES". نام می‌تواند حاوی اسلش رو به جلو باشد تا یک عنصر تو در توی XML را نشان دهد؛ به عنوان مثال "WINDOWS/VERSION/BUILD" نشان‌دهنده عنصر BUILD قرارگرفته در درون عنصر VERSION در درون عنصر WINDOWS است. یک عدد در داخل کروشه می‌تواند برای نشان دادن یکی از چندین عنصر با نام یکسان استفاده شود؛ به عنوان مثال "WINDOWS/LANGUAGES/LANGUAGE[2]" نشان‌دهنده دومین عنصر "LANGUAGE" تو در تو در درون عنصر "WINDOWS/LANGUAGES" است. هنگام اضافه کردن فهرستی از عناصر به این روش، آن‌ها باید به ترتیب متوالی مشخص شوند. توجه داشته باشید که نام عناصر به حروف بزرگ و کوچک حساس هستند. این گزینه می‌تواند چندین بار مشخص شود.

--dereference

(فقط در سیستم‌های شبه‌یونیکس) دنبال کردن پیوندهای نمادین و بایگانی فایل‌هایی که به آن‌ها اشاره می‌کنند، به جای بایگانی خود پیوندها.

--config=FILE

یک فایل پیکربندی (با کدگذاری UTF-8 یا UTF-16LE؛ اسکی ساده نیز کار می‌کند) برای ضبط ایمیج جدید مشخص می‌کند. فایل پیکربندی فایل‌هایی را تعیین می‌کند که باید در حین ضبط ایمیج رفتار ویژه‌ای با آن‌ها شود.

قالب فایل پیکربندی به سبک INI است؛ به این صورت که در بخش‌های داخل کروشه مرتب شده است. در حال حاضر، بخش‌های زیر شناسایی می‌شوند:

الگوهای مسیر ممکن است شامل نویسه‌های کنترلی '*' و '?' باشند. الگوهای نسبی (مانند ‎*.mp3‎) با نام فایل در هر دایرکتوری مطابقت دارند. الگوهای مطلق (مانند ‎/dir/file‎)، به عنوان مسیرهایی در نظر گرفته می‌شوند که از دایرکتوری اصلی در حال ضبط، یا ریشه حجم NTFS در حالت ضبط حجم NTFS شروع می‌شوند. از حروف درایو در مسیرها استفاده نکنید؛ آن‌ها نادیده گرفته خواهند شد. جداکننده‌های مسیر می‌توانند اسلش رو به جلو یا اسلش رو به عقب باشند.

خطوطی که با نویسه‌های '#' یا ';' شروع می‌شوند به عنوان توضیح (comment) در نظر گرفته شده و نادیده گرفته می‌شوند. الگوهای دارای فاصله خالی نیازی به قرار گرفتن در گیومه ندارند؛ با این حال، در صورت استفاده، هر دو نوع گیومه تکی و دوتایی پذیرفته می‌شوند.

اگر این گزینه مشخص نشود، فایل پیکربندی پیش‌فرض زیر استفاده می‌شود:

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

با این حال، در صورتی که --wimboot نیز مشخص شده باشد، رفتار ویژه‌ای اعمال می‌شود. به‌طور پیش‌فرض با مشخص شدن --wimboot، فایل Windows/System32/WimBootCompress.ini در دایرکتوری در حال ضبط به عنوان فایل پیکربندی استفاده خواهد شد. با این حال، این را می‌توان با استفاده از --config بازنویسی کرد؛ و این کار همچنین باعث می‌شود فایل پیکربندی مشخص‌شده در ایمیج WIM به عنوان Windows/System32/WimBootCompress.ini ذخیره شود و هر فایل موجود در فایل‌سیستم را بازنویسی کند.

--unix-data

(فقط در سیستم‌های شبه‌یونیکس) متادیتای اختصاصی یونیکس و فایل‌های ویژه را ذخیره می‌کند. این شامل موارد زیر است: مجوزهای استاندارد فایل یونیکس (مالک، گروه و حالت دسترسی)؛ گره‌های دستگاه، پایپ‌های نام‌گذاری‌شده و سوکت‌ها؛ و ویژگی‌های گسترش‌یافته (فقط در لینوکس). این اطلاعات بعداً می‌تواند توسط wimapply با گزینه --unix-data بازیابی شود.

اطلاعات اختصاصی یونیکس توسط نرم‌افزارهای WIM مایکروسافت و توسط نسخه ویندوز wimlib نادیده گرفته می‌شوند.

--no-acls

عدم ضبط توصیف‌کننده‌های امنیت (security descriptors) فایل‌ها.

--strict-acls

در صورتی که توصیف‌کننده امنیت کامل هر فایلی قابل خواندن نباشد، بلافاصله با خطا متوقف می‌شود. در ویندوز، رفتار پیش‌فرض بدون این گزینه این است که ابتدا تلاش می‌شود SACL از توصیف‌کننده امنیت حذف شود، سپس تلاش می‌شود توصیف‌کننده امنیت به طور کامل حذف گردد. هدف از این کار ضبط بیشترین داده ممکن بدون نیاز همیشگی به مجوزهای Administrator است. با این حال، اگر مایلید همه توصیف‌کننده‌های امنیت دقیقاً ضبط شوند، ممکن است بخواهید این گزینه را ارائه دهید، هرچند که کاربر Administrator در هر صورت باید مجوز خواندن همه چیز را داشته باشد.

--rpfix, --norpfix

تنظیم اینکه آیا مقصدهای پیوندهای نمادین مطلق (در اصطلاح ویندوز: نقاط بازپارس) اصلاح شوند یا خیر. هنگامی که فعال باشد (--rpfix)، پیوندهای نمادین مطلقی که به داخل درخت دایرکتوری در حال ضبط اشاره می‌کنند، به گونه‌ای اصلاح خواهند شد که نسبت به ریشه درخت دایرکتوری در حال ضبط مطلق باشند. هنگامی که غیرفعال باشد (--norpfix)، پیوندهای نمادین مطلق دقیقاً به همان شکلی که هستند ضبط خواهند شد.

رفتار پیش‌فرض wimcapture معادل --rpfix است. رفتار پیش‌فرض wimappend در صورتی که اصلاحات نقاط بازپارس پیش‌تر روی WIMFILE انجام شده باشد معادل --rpfix است، در غیر این صورت معادل --norpfix خواهد بود.

در مورد ضبط از چند منبع (مشخص شدن --source-list)، ارسال --norpfix توصیه می‌شود. در غیر این صورت، اصلاح نقاط بازپارس در تمام منابع ضبط که مقصدشان مکان‌های غیرریشه در ایمیج WIM است غیرفعال می‌شود، در حالی که منابع ضبط که مقصدشان ریشه WIM است رفتار پیش‌فرض پاراگراف قبل را دریافت می‌کنند.

--source-list

wimcapture و wimappend از ایجاد ایمیج WIM از چندین فایل یا دایرکتوری مجزا پشتیبانی می‌کنند. هنگامی که --source-list مشخص شود، آرگومان SOURCE نام یک فایل متنی را تعیین می‌کند که هر خط آن ۱ یا ۲ مسیر فایل جداشده با فاصله خالی است. نخستین مسیر فایل، یعنی منبع، مسیر فایل یا دایرکتوری را برای ضبط در ایمیج WIM مشخص می‌کند. این مسیر می‌تواند مطلق یا نسبت به دایرکتوری کاری فعلی باشد. دومین مسیر فایل، در صورت ارائه، مقصد است و مسیری را در ایمیج WIM مشخص می‌کند که این فایل یا دایرکتوری تحت آن ذخیره خواهد شد. اسلش‌های ابتدا و انتهای مقصد نادیده گرفته می‌شوند، مگر اینکه کاملاً از اسلش تشکیل شده باشد (مانند "/")، که نشان می‌دهد دایرکتوری قرار است به ریشه ایمیج WIM تبدیل شود. در صورت حذف، رشته مقصد به صورت پیش‌فرض همان رشته منبع خواهد بود.

نمونه‌ای از یک فایل فهرست منبع به شرح زیر است:

# ساخت ایمیج WIM از دایرکتوری 'winpe'
winpe	/
# ارسال دایرکتوری 'overlay' به '/overlay' در ایمیج WIM
overlay	/overlay
# همپوشانی یک دایرکتوری مجزا مستقیماً روی ریشه ایمیج WIM
/data/stuff	/

زیردایرکتوری‌ها در WIM بر حسب نیاز ایجاد می‌شوند. چندین دایرکتوری منبع ممکن است مقصد مشترکی داشته باشند که به معنای همپوشانی (overlay) است. در صورتی که این امر منجر به اضافه شدن چندباره یک فایل غیردایرکتوری به ایمیج WIM شود، آخرین نسخه (همان‌طور که در فایل فهرست منبع لیست شده است) بر نسخه‌های قبلی ارجحیت دارد.

مسیرهای فایلی که شامل فاصله خالی هستند می‌توانند درون گیومه تکی یا دوتایی قرار گیرند. گیومه‌ها نباید اسکیپ شوند.

خطوطی که فقط از فاصله خالی تشکیل شده‌اند و خطوطی که با '#' با فاصله‌های خالی اختیاری پیش از آن شروع می‌شوند، نادیده گرفته می‌شوند.

به عنوان یک حالت ویژه، اگر SOURCE به صورت "-" باشد، فهرست منبع به جای یک فایل خارجی از ورودی استاندارد خوانده می‌شود.

حالت ضبط حجم NTFS در سیستم‌های شبه‌یونیکس را نمی‌توان با --source-list استفاده کرد، زیرا فقط ضبط یک حجم کامل NTFS پشتیبانی می‌شود.

--pipable

در wimcapture، یک WIM «پایپ‌پذیر» اختصاصی wimlib ایجاد می‌کند که می‌تواند به طور کاملاً ترتیبی ضبط و اعمال شود. اگر WIMFILE به صورت "-" مشخص شده باشد، WIM پایپ‌پذیر مستقیماً در خروجی استاندارد نوشته می‌شود؛ در غیر این صورت، طبق معمول روی دیسک نوشته می‌شود. ایمیج موجود در WIM پایپ‌پذیر را می‌توان بعداً با wimapply، چه از روی دیسک و چه از ورودی استاندارد اعمال کرد. یک کاربرد متداول WIMهای پایپ‌پذیر ممکن است شامل استریم کردن ایمیج WIM به یک سرور راه دور هنگام ضبط آن، و/یا استریم کردن ایمیج WIM از یک سرور راه دور هنگام اعمال آن باشد.

به طور کلی، تمام دستورهای wimlib-imagex روی هر دو نوع WIMهای پایپ‌پذیر و غیرپایپ‌پذیر کار می‌کنند. همچنین می‌توان از wimoptimize و wimexport برای تبدیل بین WIMهای پایپ‌پذیر و غیرپایپ‌پذیر استفاده کرد. با این حال، چند محدودیت برای WIMهای پایپ‌پذیر وجود دارد:

--not-pipable

در wimappend، فایل WIM را در قالب غیرپایپ‌پذیر (عادی) بازسازی می‌کند. این گزینه فقط در صورتی مفید است که بخواهید ایمیجی را به یک WIM پایپ‌پذیر اضافه کنید (گزینه --pipable را ببینید) که می‌خواهید به جای آن در قالب غیرپایپ‌پذیر باشد. توجه داشته باشید که از wimoptimize(1) نیز می‌توان برای تبدیل بین WIMهای غیرپایپ‌پذیر و پایپ‌پذیر استفاده کرد.

--update-of=[WIMFILE:]IMAGE

اشاره می‌کند به اینکه ایمیج در حال ضبط یا الحاق از SOURCE عمدتاً همان ایمیج موجود IMAGE در WIMFILE است، اما در زمان دیرتری ضبط شده و احتمالاً در این فاصله زمانی تغییراتی داشته است. این قابلیت برای استفاده در پشتیبان‌گیری‌های افزایشی از همان فایل‌سیستم یا درخت دایرکتوری طراحی شده است. IMAGE می‌تواند یک ایندکس مبتنی بر ۱ یا نام یک ایمیج موجود در WIMFILE باشد. همچنین می‌تواند یک عدد صحیح منفی باشد تا ایندکس‌گذاری معکوس در ایمیج‌ها انجام شود (مثلاً ۱- به معنای آخرین ایمیج موجود در WIMFILE است).

هنگامی که این گزینه ارائه شود، ضبط یا الحاق ایمیج جدید با نخواندن فایل‌هایی که بر اساس متادیتایی مانند مهرهای زمانی به نظر می‌رسد از زمان بایگانی در IMAGE موجود تغییر نکرده‌اند، بهینه‌سازی می‌شود. به استثنای دستکاری مهرهای زمانی، این گزینه فقط بر عملکرد تأثیر می‌گذارد و ایمیج WIM حاصل را تغییر نمی‌دهد (اما یادداشت زیر را ببینید).

همان‌طور که نشان داده شده است، ساختار دستوری کامل برای آرگومان این گزینه تعیین فایل WIM، دونقطه و ایمیج است؛ برای مثال، "--update-of mywim.wim:1". با این حال، اگر --delta-from دقیقاً یک بار مشخص شده باشد، فایل WIM و دونقطه می‌توانند حذف شوند، که در این صورت WIM به طور پیش‌فرض همان مشخص‌شده در --delta-from خواهد بود؛ یا اگر عملیات wimappend باشد نه wimcapture، در این صورت WIM به طور پیش‌فرض همان فایلی خواهد بود که به آن الحاق می‌شود.

نکته: در نسخه ویندوز wimlib، مشاهده شده است که حالت --update-of در تشخیص تغییرات در محتویات فایل کاملاً قابل اعتماد نیست و گاهی اوقات باعث می‌شود محتویات قدیمی چند فایل به جای محتویات فعلی بایگانی شوند. علت این مشکل این است که ویندوز بلافاصله پس از هر بار نوشتن در یک فایل، مهر زمانی آخرین تغییر آن را به‌روزرسانی نمی‌کند. متأسفانه، هیچ روش شناخته‌شده‌ای برای برنامه‌هایی مانند wimlib وجود ندارد که این باگ را به طور خودکار دور بزنند. دور زدن‌های دستی امکان‌پذیر است؛ از نظر تئوری، انجام هر عملی که باعث بسته شدن فایل‌های مشکل‌ساز شود، مانند راه‌اندازی مجدد برنامه‌ها یا خود رایانه، باید باعث به‌روزرسانی مهرهای زمانی آخرین تغییر فایل‌ها شود. همچنین توجه داشته باشید که wimlib در تعیین اینکه آیا یک فایل تغییر کرده است یا خیر، اندازه فایل‌ها و همچنین مهرهای زمانی را مقایسه می‌کند، که به کاهش احتمال بروز این مشکل کمک می‌نماید؛ و این مشکل در سایر سیستم‌های عامل مانند لینوکس که مهرهای زمانی آخرین تغییر فایل‌ها را به درستی نگهداری می‌کنند رخ نمی‌دهد.

--delta-from=WIMFILE

ضبط یا الحاق ایمیج جدید به عنوان یک "دلتا" (تغییرات) نسبت به WIMFILE. هر داده فایلی که معمولاً نیاز به بایگانی در WIM جدید یا به‌روزرسانی‌شده دارد، اگر از قبل در WIMFILE که دلتا بر پایه آن است وجود داشته باشد، حذف می‌شود. WIM حاصل همچنان حاوی یک کپی کامل از متادیتای ایمیج خواهد بود، اما این متادیتا معمولاً تنها بخش کوچکی از حجم کل یک WIM است.

این گزینه می‌تواند چندین بار مشخص شود، که در این صورت دلتا WIM حاصل فقط شامل داده‌های فایلی خواهد بود که در هیچ یک از WIMهای پایه مشخص‌شده وجود نداشته باشند.

برای کار بر روی دلتا WIM حاصل با استفاده از سایر دستورها مانند wimapply، باید دلتا WIM را به عنوان فایل WIM برای عملیات مشخص کنید، اما همچنین باید با استفاده از گزینه --ref به WIM(های) پایه ارجاع دهید. هشدار: برای حفظ عملکرد صحیح دلتا WIM، پس از ضبط دلتا از WIM(های) پایه، فقط می‌توانید فایل‌ها و ایمیج‌هایی را به WIM(های) پایه اضافه کنید، نه اینکه حذف نمایید.

گزینه --delta-from می‌تواند با --update-of ترکیب شود تا سرعت ضبط یک دلتا WIM افزایش یابد.

به عنوان مثال، توالی پشتیبان‌گیری و بازیابی زیر را در نظر بگیرید:

# پشتیبان‌گیری اولیه
$ 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

با این حال، توجه داشته باشید که به عنوان جایگزینی برای توالی بالا که از یک دلتا WIM استفاده می‌کرد، نسخه پشتیبان دوم می‌توانست به سادگی با استفاده از wimappend به عنوان ایمیج جدید به WIM الصاق شود. دلتا WIMها فقط باید در صورتی استفاده شوند که بخواهید پشتیبان‌ها یا ایمیج‌ها را بر پایه یک فایل مجزا و بزرگ که به ندرت تغییر می‌کند پایه‌گذاری کنید.

گزینه --delta-from توسط هر دو دستور wimcapture و wimappend پشتیبانی می‌شود.

دلتا WIMها با نرم‌افزارهای WIM مایکروسافت سازگار هستند. برای مثال، می‌توانید از گزینه /ref در ImageX برای ارجاع به WIM(های) پایه، مشابه بالا استفاده کنید.

نکته اضافی: wimlib به اندازه کافی تعمیم‌یافته است به طوری که می‌توانید در واقع --pipable و --delta-from را با هم ترکیب کنید تا دلتا WIMهای پایپ‌پذیر بسازید. در چنین مواردی، WIM(های) پایه نیز باید مانند دلتا WIM به صورت پایپ‌پذیر ضبط شوند، و هنگام اعمال ایمیج، WIM(های) پایه باید پس از دلتا WIM از طریق پایپ ارسال شوند.

--wimboot

ایمیج را به عنوان سازگار با WIMBoot علامت‌گذاری می‌کند. برای اطلاعات بیشتر در مورد WIMBoot به مستندات مایکروسافت مراجعه کنید. با wimcapture این گزینه نوع فشرده‌سازی را روی XPRESS و اندازه تکه را روی ۴۰۹۶ بایت تنظیم می‌کند؛ با این حال، این مقادیر همچنان می‌توانند به ترتیب از طریق پارامترهای --compress و --chunk-size بازنویسی شوند. علاوه بر این، این گزینه در صورت وجود و دسترسی، فایل پیکربندی را روی SOURCE\Windows\System32\WimBootCompress.ini تنظیم می‌کند؛ با این حال، این مورد نیز ممکن است از طریق پارامتر --config بازنویسی شود.

--unsafe-compact

با wimappend، بایگانی WIM را درجا فشرده (compact) کرده و داده‌های جدید را الحاق می‌کند و "حفره‌ها" را از بین می‌برد. این روش کارآمد است، اما به طور کلی این گزینه نباید استفاده شود زیرا فشرده‌سازی ناموفق یا متوقف‌شده باعث خراب شدن بایگانی WIM می‌شود. برای اطلاعات بیشتر، مستندات مربوط به این گزینه را در wimoptimize(1) ببینید.

--snapshot

یک تصویر لحظه‌ای (snapshot) موقت از سیستم فایل دایرکتوری منبع ایجاد کرده و فایل‌ها را از آن ضبط می‌کند. در حال حاضر، این گزینه فقط در ویندوز پشتیبانی می‌شود، جایی که از Volume Shadow Copy Service (VSS) استفاده می‌کند. با استفاده از این گزینه، می‌توانید یک پشتیبان منسجم از حجم سیستم یک ویندوز در حال اجرا ایجاد کنید بدون اینکه با مشکلات فایل‌های قفل‌شده مواجه شوید. برای اینکه اسنپ‌شات VSS با موفقیت ایجاد شود، wimlib-imagex باید با دسترسی Administrator اجرا شود و نمی‌تواند در حالت WoW64 اجرا گردد (یعنی اگر ویندوز ۶۴ بیتی است، wimlib-imagex نیز باید ۶۴ بیتی باشد).

--create

با wimappend، اگر فایل WIM هنوز وجود نداشته باشد، آن را ایجاد می‌کند (مانند wimcapture).

نکات (NOTES)

دستور wimappend از الصاق یک ایمیج به یک WIM تکه‌تکه‌شده (split WIM) پشتیبانی نمی‌کند.

به جز زمان استفاده از --unsafe-compact، سقط کردن دستور wimappend در میانه راه بی‌خطر است؛ با این حال، پس از انجام این کار، توصیه می‌شود wimoptimize را اجرا کنید تا هر داده‌ای که به فایل فیزیکی WIM الحاق شده اما هنوز در ساختار WIM گنجانده نشده است حذف شود، مگر اینکه WIM در حال بازسازی کامل بوده باشد (مثلاً با --rebuild)، که در این صورت باید فایل موقت باقی‌مانده را حذف کنید.

ابزار wimlib-imagex فایل‌های WIM سازگار با نرم‌افزارهای مایکروسافت (WIMGAPI, ImageX, DISM) ایجاد می‌کند، با برخی ملاحظات:

•

با wimlib-imagex در سیستم‌های شبه‌یونیکس، امکان ایجاد یک ایمیج WIM حاوی فایل‌هایی با نام‌هایی که فقط در بزرگی و کوچکی حروف تفاوت دارند، یا فایل‌هایی با نام‌های حاوی نویسه‌های ':', '*', '?', '"', '<', '>', '|' یا '\' وجود دارد که در فایل‌سیستم‌های منطبق بر POSIX معتبر هستند اما در ویندوز معتبر نیستند. هشدار داده می‌شود که چنین فایل‌هایی به‌طور پیش‌فرض توسط نسخه ویندوز wimlib-imagex استخراج نخواهند شد، و (حتی بدتر) ابزار ImageX مایکروسافت ممکن است با چنین نام‌هایی دچار سردرگمی شده و استخراج ایمیج را در میانه راه متوقف کند.

•

فایل‌های WIM پایپ‌پذیر با نرم‌افزارهای مایکروسافت ناسازگار هستند. WIMهای پایپ‌پذیر فقط در صورتی ایجاد می‌شوند که WIMFILE به صورت "-" (خروجی استاندارد) مشخص شده باشد یا پرچم --pipable تعیین شده باشد.

•

فایل‌های WIM ضبط‌شده با اندازه تکه غیرپیش‌فرض (با گزینه --chunk-size) یا به عنوان بایگانی‌های یکپارچه (با گزینه --solid) یا با فشرده‌سازی LZMS (با --compress=LZMS یا --compress=recovery) سطوح متفاوتی از سازگاری با نرم‌افزارهای مایکروسافت دارند. به طور کلی، نسخه‌های جدیدتر نرم‌افزارهای مایکروسافت سازگاری بیشتری دارند.

مثال‌ها (EXAMPLES)

مثال اول: ایجاد یک WIM جدید به نام 'mywim.wim' با فشرده‌سازی LZX (یا "maximum") که حاوی یک ایمیج ضبط‌شده از درخت دایرکتوری 'somedir' خواهد بود. توجه داشته باشید که نام ایمیج نیازی به مشخص شدن ندارد و به طور پیش‌فرض 'somedir' خواهد بود:

سپس، الحاق ایمیج یک درخت دایرکتوری دیگر به WIM ایجادشده در بالا:

بسیار ساده، و مثال‌های بالا از ایجاد ایمیج از درخت‌های دایرکتوری هم در سیستم‌های شبه‌یونیکس و هم در ویندوز کار می‌کنند. سپس، ضبط یک WIM با چندین گزینه غیرپیش‌فرض، از جمله فشرده‌سازی XPRESS (یا "fast")، اطلاعات یکپارچگی اضافی، عدم دستکاری پیوندهای نمادین مطلق، و یک نام و توضیح برای ایمیج:

در یک سیستم شبه‌یونیکس، یک حجم کامل NTFS را با استفاده از حالت ضبط حجم NTFS در یونیکس (NTFS VOLUME CAPTURE - UNIX) در یک WIM جدید ضبط کرده و نام ایمیج را "Windows 7" بگذارید:

یا در ویندوز، برای ضبط یک حجم کامل NTFS باید در عوض دایرکتوری ریشه حجم سوارشده را مشخص کنید، برای مثال:

مشابه مثال یونیکس در بالا، اما ضبط WIM در قالب "پایپ‌پذیر" اختصاصی wimlib که می‌تواند به wimapply پایپ شود:

مشابه بالا، اما به جای نوشتن WIM پایپ‌پذیر در فایل "windows7.wim"، آن را مستقیماً در خروجی استاندارد از طریق یک پایپ به برنامه دیگری به نام "someprog" بنویسید، که می‌تواند برای مثال برنامه‌ای یا اسکریپتی باشد که داده‌ها را به یک سرور استریم می‌کند:

همچنین ببینید (SEE ALSO)

wimlib-imagex(1), wimapply(1), wimoptimize(1)