WIMAPPLY(1) User Commands WIMAPPLY(1)

wimapply - اعمال یک تصویر WIM

wimapply WIMFILE [IMAGE] TARGET [OPTION...]

دستور wimapply، یا معادل آن wimlib-imagex apply، یک یا تمام تصاویر را از بایگانی تصویری ویندوز (WIM) WIMFILE استخراج («اعمال») می‌کند.

شناسه IMAGE تصویر مورد نظر برای استخراج در WIMFILE را مشخص می‌کند. این مقدار می‌تواند نمایه مبتنی بر ۱ یک تصویر، نام تصویر یا کلمه کلیدی «all» برای مشخص کردن همه تصاویر باشد. اگر WIMFILE تنها شامل یک تصویر باشد، می‌توان از این مقدار صرف‌نظر کرد. برای فهرست کردن تصاویر موجود در WIMFILE می‌توانید از wiminfo(1) استفاده کنید.

شناسه TARGET مشخص می‌کند که تصویر(ها) در کجا استخراج شوند. اگر TARGET یک دایرکتوری باشد، تصویر(ها) مطابق با بخش استخراج در دایرکتوری (یونیکس) (DIRECTORY EXTRACTION (UNIX)) یا استخراج در دایرکتوری (ویندوز) (DIRECTORY EXTRACTION (WINDOWS)) در آن دایرکتوری استخراج خواهند شد. اگر TARGET وجود نداشته باشد، ابتدا یک دایرکتوری در آنجا ایجاد می‌شود. متناوباً، اگر TARGET یک دستگاه بلوکی یونیکس را مشخص کند، تصویر همان‌طور که در بخش استخراج در حجم دیسک NTFS (یونیکس) (NTFS VOLUME EXTRACTION (UNIX)) شرح داده شده در آن استخراج خواهد شد.

توجه داشته باشید که wimapply برای استخراج یا «اعمال» تصاویر کامل WIM طراحی شده است. اگر در عوض می‌خواهید تنها فایل‌ها یا دایرکتوری‌های خاصی را از یک تصویر WIM استخراج کنید، از wimextract(1) استفاده کنید.

اگر IMAGE برابر با «all» باشد، تمام تصاویر موجود در WIMFILE در زیردایرکتوری‌هایی از TARGET که هم‌نام تصاویر هستند استخراج خواهند شد، و در صورتی که تصویری فاقد نام یا دارای نام غیرمعمول باشد، از نمایه تصویر به عنوان نام استفاده می‌شود. این قابلیت هنوز در حالت استخراج در حجم دیسک NTFS (یونیکس) (NTFS VOLUME EXTRACTION (UNIX)) پشتیبانی نمی‌شود.

اگر WIMFILE برابر با «-» باشد، WIM به جای دیسک از ورودی استاندارد خوانده می‌شود. برای اطلاعات بیشتر بخش تصاویر WIM لوله‌پذیر (PIPABLE WIMS) را ببینید.

در سیستم‌های شبه‌یونیکس، تصویر WIM می‌تواند در یک دایرکتوری استخراج شود. این حالت این محدودیت را دارد که فراداده‌های مختص NTFS یا ویندوز استخراج نخواهند شد. اگرچه برخی مفاهیم مانند پیوندهای سخت، پیوندهای نمادین، برچسب‌های زمانی آخرین دسترسی و آخرین تغییر به معادل‌های یونیکسی خود ترجمه می‌شوند، سایر فراداده‌ها از دست خواهند رفت (همراه با هشدارهایی که داده می‌شود). به‌ویژه، انواع فراداده‌های زیر در این حالت استخراج نخواهند شد:

•
پرچم‌های صفت فایل ویندوز
•
توصیف‌کننده‌های امنیت ویندوز (مانند مالکان فایل و DACLها)
•
برچسب‌های زمانی ایجاد فایل
•
نقاط بازتحلیل (Reparse points) به جز پیوندهای نمادین و نقاط پیوند (junction points)
•
جریان‌های داده نام‌گذاری‌شده (Named data streams)
•
نام‌های کوتاه فایل (که به عنوان نام‌های 8.3 یا نام‌های DOS نیز شناخته می‌شوند).
•
شناسه‌های شیء (Object IDs)

همین محدودیت‌ها برای wimextract نیز اعمال می‌شوند. بنابراین، این حالت در شرایطی بیشترین کاربرد را دارد که فراداده‌های مختص NTFS یا ویندوز اهمیتی ندارند؛ برای مثال هنگام تمایل به استخراج فایل‌های خاص، یا هنگام بایگانی فایل‌ها صرفاً در سیستم‌های شبه‌یونیکس، احتمالاً در ترکیب با --unix-data. هنگامی که فراداده‌های مختص ویندوز مهم باشند، یا باید از حالت استخراج در حجم دیسک NTFS (یونیکس) (NTFS VOLUME EXTRACTION (UNIX)) استفاده شود، یا از نسخه ویندوز wimlib استفاده گردد (بخش استخراج در دایرکتوری (ویندوز) (DIRECTORY EXTRACTION (WINDOWS)) را ببینید).

در سیستم‌های شبه‌یونیکس، TARGET می‌تواند به عنوان یک دستگاه بلوکی (مانند /dev/sda3) شامل یک حجم دیسک NTFS سوارنشده (unmounted) نیز مشخص شود. در این حالت، wimapply از libntfs-3g برای اعمال تصویر WIM مشخص‌شده به دایرکتوری ریشه حجم دیسک NTFS استفاده می‌کند. حجم دیسک مقصد باید خالی باشد، برای مثال به تازگی توسط mkntfs(8) ایجاد شده باشد. در این حالت، داده‌ها و فراداده‌های مختص NTFS و ویندوز استخراج خواهند شد، از جمله موارد زیر:

•
تمام جریان‌های داده در همه فایل‌ها به جز فایل‌های رمزشده، از جمله جریان داده بدون نام و همچنین تمام جریان‌های داده نام‌گذاری‌شده.
•
نقاط بازتحلیل (Reparse points)، شامل پیوندهای نمادین، نقاط پیوند (junction points) و سایر نقاط بازتحلیل.
•
برچسب‌های زمانی ایجاد، دسترسی و تغییر فایل و دایرکتوری، با استفاده از دقت بومی NTFS برابر با ۱۰۰ نانوثانیه.
•
توصیف‌کننده‌های امنیت ویندوز، شامل تمامی مؤلفه‌ها (مالک، گروه، DACL و SACL).
•
پرچم‌های صفت فایل ویندوز
•
تمام نام‌های تمامی فایل‌ها، از جمله نام‌ها در فضای نام Win32، فضای نام DOS، فضای نام Win32+DOS و فضای نام POSIX. این شامل پیوندهای سخت نیز می‌شود.
•
شناسه‌های شیء (Object IDs).

با این حال، فایل‌های رمزشده استخراج نخواهند شد.

همچنین بازیابی صفات توسعه‌یافته (EAs) هنوز در این حالت پشتیبانی نمی‌شود.

صرف نظر از این، از آنجا که تقریباً تمام اطلاعات تصویر WIM در این حالت بازیابی می‌شوند، امکان بازیابی یک تصویر از نصب واقعی ویندوز با استفاده از wimapply روی یک سیستم شبه‌یونیکس (به عنوان جایگزینی برای استفاده از wimapply یا DISM در ویندوز) وجود دارد (و کاملاً پشتیبانی می‌شود). در بخش مثال‌ها (EXAMPLES) در ادامه، نمونه‌ای از اعمال یک تصویر از یک فایل «install.wim» که ممکن است در رسانه نصب ویندوز یافت شود آورده شده است.

توجه داشته باشید که برای راه‌اندازی (بوت) واقعی ویندوز (Vista یا جدیدتر) از یک تصویر اعمال‌شده «install.wim»، باید پارتیشن را به عنوان «قابل بوت» (bootable) علامت‌گذاری کرده و فایل‌های مختلف بوت مانند \BOOTMGR و \BOOT\BCD را تنظیم کنید. کار دوم به ساده‌ترین شکل با اجرای bcdboot.exe از یک سیستم زنده ویندوز مانند Windows PE انجام می‌شود، اما گزینه‌های دیگری نیز وجود دارد.

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

در ویندوز، wimapply (و wimextract) به طور بومی از فراداده‌های مختص NTFS و ویندوز پشتیبانی می‌کنند. برای بهترین نتیجه، دایرکتوری مقصد باید روی یک حجم دیسک NTFS قرار داشته باشد و برنامه با امتیازات Administrator اجرا شود؛ با این حال، سیستم‌فایل‌های غیر NTFS و اجرا بدون امتیازات Administrator نیز با در نظر گرفتن محدودیت‌ها پشتیبانی می‌شوند.

در ویندوز، wimapply تلاش می‌کند تا حد ممکن داده‌ها و فراداده‌ها را استخراج کند، از جمله:

•
تمام جریان‌های داده در همه فایل‌ها. این شامل محتوای پیش‌فرض فایل و همچنین جریان‌های داده نام‌گذاری‌شده در صورت پشتیبانی توسط حجم دیسک مقصد است.
•
نقاط بازتحلیل، شامل پیوندهای نمادین، نقاط پیوند و سایر نقاط بازتحلیل در صورت پشتیبانی توسط حجم دیسک مقصد. بازیابی پیوندهای نمادین نیازمند امتیازات Administrator است. همچنین برای جزئیات در مورد نحوه استخراج پیوندهای نمادین مطلق و نقاط پیوند، --rpfix و --norpfix را ببینید.
•
برچسب‌های زمانی ایجاد، دسترسی و تغییر فایل و دایرکتوری، با بالاترین دقت پشتیبانی‌شده توسط حجم دیسک مقصد.
•
توصیف‌کننده‌های امنیت، در صورتی که توسط سیستم‌فایل پشتیبانی شوند و --no-acls مشخص نشده باشد. توجه داشته باشید که این امر عموماً نیازمند امتیازات Administrator است و اگر برنامه بدون دسترسی‌های Administrator اجرا شود، ممکن است تنها تا حدی موفقیت‌آمیز باشد (--strict-acls را ببینید).
•
پرچم‌های صفت فایل، شامل مخفی (hidden)، فشرده (compressed)، رمزشده (encrypted)، تنک (sparse) و غیره، در صورت پشتیبانی توسط سیستم‌فایل.
•
نام‌های کوتاه فایل (که به عنوان نام‌های 8.3 یا نام‌های DOS نیز شناخته می‌شوند).
•
پیوندهای سخت، در صورت پشتیبانی توسط سیستم‌فایل مقصد.
•
شناسه‌های شیء (Object IDs)، در صورت پشتیبانی توسط سیستم‌فایل مقصد.
•
صفات توسعه‌یافته (EAs)، در صورت پشتیبانی توسط سیستم‌فایل مقصد.

نکات تکمیلی درباره استخراج فایل‌ها در ویندوز:

•
در صورت عدم امکان استخراج دقیق فراداده و داده‌های تصویر WIM به دلیل محدودیت‌های سیستم‌فایل مقصد، wimapply هشدارهایی صادر خواهد کرد.
•
از آنجا که فایل‌های رمزشده (با صفت FILE_ATTRIBUTE_ENCRYPTED) به صورت متن ساده در تصویر WIM ذخیره نمی‌شوند، wimapply نمی‌تواند فایل‌های رمزشده را در سیستم‌فایل‌هایی که از رمزنگاری پشتیبانی نمی‌کنند بازیابی کند. بنابراین، در چنین سیستم‌فایل‌هایی، فایل‌های رمزشده استخراج نخواهند شد. افزون بر این، حتی اگر فایل‌های رمزشده در سیستم‌فایلی که از رمزنگاری پشتیبانی می‌کند بازیابی شوند، تنها در صورتی قابل رمزگشایی خواهند بود که کلید رمزگشایی در دسترس باشد.
•
فایل‌هایی با نام‌هایی که در ویندوز قابل نمایش نیستند به طور پیش‌فرض استخراج نخواهند شد؛ --include-invalid-names را ببینید.
•
فایل‌هایی با مسیر کامل بیش از ۲۶۰ نویسه (اصطلاحاً MAX_PATH) استخراج خواهند شد، اما توجه داشته باشید که این فایل‌ها برای بیشتر نرم‌افزارهای ویندوز غیرقابل دسترس خواهند بود و ممکن است به راحتی قابل حذف نباشند.
•
در ویندوز، مگر اینکه گزینه --no-acls مشخص شده باشد، wimlib تلاش خواهد کرد توصیف‌کننده‌های امنیت فایل‌ها را دقیقاً همان‌طور که در تصویر WIM ارائه شده‌اند بازیابی کند. توجه داشته باشید که نصب‌های معمولی ویندوز شامل فایل‌هایی هستند که توصیف‌کننده‌های امنیت آنها به Administrator اجازه حذف آنها را نمی‌دهد. بنابراین، پس از استخراج نمی‌توان چنین فایل‌هایی را حذف کرد، یا در برخی موارد حتی خواند، مگر اینکه با یک برنامه تخصصی پردازش شوند که می‌داند چگونه امتیازات SE_RESTORE_NAME و/یا SE_BACKUP_NAME را که امکان نادیده گرفتن فهرست‌های کنترل دسترسی را می‌دهند، به دست آورد. این یک باگ در wimlib نیست (که طبق طراحی خود برای بازیابی صحیح داده‌های بایگانی‌شده کار می‌کند)، بلکه مشکلی ناشی از حقوق دسترسی است که ویندوز روی فایل‌های خاصی اعمال می‌کند. با این حال، اگر فقط داده‌های فایل را می‌خواهید و به توصیف‌کننده‌های امنیت اهمیتی نمی‌دهید، از --no-acls برای صرف‌نظر کردن از بازیابی تمام توصیف‌کننده‌های امنیت استفاده کنید.
•
هشدار مشابهی با موارد بالا در مورد صفت‌های فایل مانند Readonly ،Hidden و System نیز صدق می‌کند. طبق طراحی، wimlib در ویندوز چنین صفت‌های فایلی را بازیابی خواهد کرد؛ بنابراین، فایل‌های استخراج‌شده ممکن است این صفت‌ها را داشته باشند. اگر این مورد نظر شما نیست، از گزینه --no-attributes استفاده کنید..SH "WIMهای چندبخشی (SPLIT WIMS)" شما می‌توانید از wimapply برای اعمال ایمیج‌ها از یک WIM چندبخشی (split WIM)، یا از wimextract برای استخراج فایل‌ها از یک WIM چندبخشی استفاده کنید. آرگومان WIMFILE باید بخش نخست WIM چندبخشی را مشخص کند، در حالی که بخش‌های دیگر WIM چندبخشی باید در یک یا چند گزینه --ref="GLOB" مشخص شوند. از آنجا که قابلیت globbing در خود گزینه --ref تعبیه شده است، معمولاً تنها یک گزینه --ref کفایت می‌کند. برای مثال، نام بخش‌های یک WIM چندبخشی معمولاً چنین ساختاری دارند:
mywim.swm
mywim2.swm
mywim3.swm
mywim4.swm
mywim5.swm

برای اعمال نخستین ایمیج از این WIM چندبخشی به دایرکتوری "dir"، اجرا کنید:

wimapply mywim.swm 1 dir --ref="mywim*.swm"

همچنین wimapply از اعمال یک WIM از یک فایل فاقد قابلیت جستجو (nonseekable)، مانند یک لوله (pipe) نیز پشتیبانی می‌کند، به شرطی که WIM در قالب لوله‌پذیرِ مختص wimlib با استفاده از --pipable ایجاد شده باشد (نگاه کنید به wimcapture(1)). برای استفاده از ورودی استاندارد به عنوان WIM، مقدار "-" را به عنوان WIMFILE مشخص کنید. یک کاربرد احتمالی این ویژگی، اعمال یک ایمیج WIM در حال استریم از شبکه است. برای مثال، جهت اعمال نخستین ایمیج از یک فایل WIM موجود در یک کارساز HTTP به یک حجم NTFS روی /dev/sda1، دستوری شبیه به این را اجرا کنید:

wget -O - https://myserver/mywim.wim | wimapply - 1 /dev/sda1

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

پیش از اعمال ایمیج، اگر WIMFILE دارای اطلاعات تکمیلی یکپارچگی باشد، سلامت آن را راستی‌آزمایی می‌کند.
الگوی نام فایل (glob) مربوط به WIMهای تکمیلی یا بخش‌های WIM چندبخشی برای ارجاع منابع از آن‌ها. بخش SPLIT_WIMS را ببینید. این گزینه می‌تواند چندین بار تکرار شود. نکته: GLOB در گیومه قرار گرفته زیرا توسط wimapply تفسیر می‌شود و برای جلوگیری از بسط شل (shell expansion) ممکن است نیاز به قرار گرفتن درون نقل‌قول داشته باشد.
مشخص می‌کند که آیا مقاصد پیوندهای نمادین مطلق (در اصطلاح ویندوز: reparse points) اصلاح شوند یا خیر. هنگام فعال بودن (--rpfix)، چنین فرض می‌شود که پیوندهای نمادین مطلق استخراج‌شده که در ایمیج WIM به عنوان اصلاح‌شده علامت‌گذاری شده‌اند، مقاصد مطلقی نسبت به ریشه ایمیج دارند؛ از این رو wimapply مسیر مطلق دایرکتوری مقصد استخراج را به ابتدای مقاصد آن‌ها می‌افزاید. هدف این است که بتوانید ایمیجی شامل پیوندهای نمادین مطلق را اعمال کنید و پس از استخراج به هر مکانی، پیوندها همچنان معتبر باشند.
اگر هر یک از ایمیج‌های موجود در WIMFILE همراه با اصلاحات reparse-point ذخیره شده باشند، رفتار پیش‌فرض --rpfix است. در غیر این صورت، پیش‌فرض --norpfix خواهد بود.
اصلاحات reparse point هرگز در حالت استخراج به حجم NTFS در سیستم‌های شبه‌یونیکس انجام نمی‌شود.
(تنها در سیستم‌های شبه‌یونیکس) بازگردانی متاداده‌های مخصوص یونیکس و فایل‌های ویژه‌ای که توسط wimcapture با گزینه --unix-data ذخیره شده بودند. این موارد شامل: مجوزهای استاندارد یونیکس برای فایل (مالک، گروه، و حالت دسترسی)؛ گره‌های دستگاه (device nodes)، لوله‌های نام‌گذاری‌شده (named pipes) و سوکت‌ها؛ و مشخصه‌های گسترش‌یافته (تنها در لینوکس) است.
توصیف‌کننده‌های امنیتی (security descriptors) را روی فایل‌ها و دایرکتوری‌های استخراج‌شده بازیابی نمی‌کند.
در صورتی که توصیف‌کننده امنیتی کاملِ هر فایل یا دایرکتوری دقیقاً مطابق آنچه در فایل WIM تعیین شده قابل تنظیم نباشد، بلافاصله با خطا خارج می‌شود. اگر این گزینه مشخص نشود، هنگامی که wimapply در ویندوز مجوزهای لازم برای تنظیم توصیف‌کننده امنیتی روی یک فایل استخراج‌شده را نداشته باشد، به تنظیم ناقص آن (مثلاً با صرف‌نظر از SACL) بسنده می‌کند و در بدترین حالت آن را کاملاً نادیده می‌گیرد. با این حال، این مشکل معمولاً تنها زمانی رخ می‌دهد که wimapply بدون دسترسی‌های Administrator اجرا شود. همچنین در سیستم‌های شبه‌یونیکس، این پرچم می‌تواند با --unix-data ترکیب شود تا در صورت عدم امکان اعمال مجوزهای یونیکس روی یک فایل استخراج‌شده، wimapply خطایی صادر کند.
ویژگی‌های فایل ویندوز مانند readonly، hidden و غیره را بازیابی نمی‌کند.
فایل‌ها و دایرکتوری‌های دارای نام‌های نامعتبر را به جای نادیده گرفتن، با جایگزین کردن نویسه‌ها و افزودن یک پسوند استخراج می‌کند. این که دقیقاً چه چیزی یک نام «نامعتبر» تلقی می‌شود، به پلتفرم بستگی دارد.
در سیستم‌های سازگار با POSIX، نام فایل‌ها به بزرگی و کوچکی حروف حساس بوده و می‌توانند شامل هر بایتی به جز '\0' و '/' باشند؛ بنابراین در یک سیستم سازگار با POSIX، این گزینه تنها در حالت نادری اثرگذار خواهد بود که ایمیج WIM به دلیلی نام فایلی شامل این نویسه‌ها داشته باشد.
در ویندوز، نام فایل‌ها به بزرگی و کوچکی حروف حساس نیست (*)، نمی‌تواند شامل نویسه‌های کنترلی باشد، و نمی‌تواند حاوی نویسه‌های '/'، '\0'، '\'، ':'، '*'، '?'، '"'، '<'، '>' یا '|' باشد. به‌طور معمول، فایل‌های درون ایمیج‌های WIM نیز باید این شرایط را رعایت کنند. با این حال این موضوع تضمین‌شده نیست؛ به‌ویژه یک ایمیج WIM که با wimcapture در یک سیستم سازگار با POSIX ذخیره شده باشد ممکن است شامل چنین فایل‌هایی باشد. به‌طور پیش‌فرض، نام‌های نامعتبر نادیده گرفته می‌شوند و اگر چندین نام تنها در بزرگی و کوچکی حروف با یکدیگر تفاوت داشته باشند، یکی از آن‌ها به‌صورت تصادفی برای استخراج انتخاب می‌شود؛ اما با --include-invalid-names، تمام نام‌ها پاک‌سازی شده و به نحوی استخراج خواهند شد.
(*) مگر اینکه تنظیم ObCaseInsensitive در رجیستری ویندوز روی 0 تنظیم شده باشد، که در این صورت برخی نرم‌افزارها، از جمله نسخه ویندوز wimapply، حساسیت به بزرگی و کوچکی حروف را روی NTFS و دیگر سیستم‌فایل‌های سازگار رعایت خواهند کرد.
تنها در ویندوز: به جای استخراج خود فایل‌ها، «فایل‌های اشاره‌گر» (pointer files) را به آرشیو(های) WIM بازمی‌گرداند. این قابلیت می‌تواند صرفه‌جویی چشمگیری در فضای دیسک به همراه داشته باشد. با این حال، معایبی نیز دارد، از جمله عدم امکان حذف آرشیو(های) WIM و احتمالاً کندتر شدن دسترسی به فایل‌ها. برای اطلاعات بیشتر به مستندات مایکروسافت درباره «WIMBoot» مراجعه کنید.
در صورت وجود، بخش [PrepopulateList] از فایل \Windows\System32\WimBootCompress.ini در ایمیج WIM خوانده خواهد شد. فایل‌های منطبق با هر یک از این الگوها به‌صورت معمولی استخراج می‌شوند و نه به‌صورت فایل‌های اشاره‌گر WIMBoot. این موضوع برای فایل‌هایی که ویندوز در اوایل فرایند بوت به خواندن آن‌ها نیاز دارد سودمند است.
این گزینه تنها زمانی کار می‌کند که برنامه به صورت Administrator اجرا شده باشد و حجم مقصد NTFS یا سیستم‌فایل دیگری باشد که از reparse points پشتیبانی کند.
همچنین، این گزینه بهترین عملکرد را در ویندوز 8.1 آپدیت 1 یا بالاتر دارد، چرا که این نخستین نسخه از ویندوز است که درایور فیلتر سیستم‌فایل همپوشانی ویندوز («WOF») را به همراه دارد. در صورت شناسایی درایور WOF، ابزار wimlib فایل‌های اشاره‌گر WIMBoot را با استفاده از ioctlهای مستند ارائه‌شده توسط WOF ایجاد خواهد کرد.
در غیر این صورت، چنانچه درایور WOF یافت نشود، wimlib نقاط reparse را ایجاد کرده و فایل "\System Volume Information\WimOverlay.dat" را روی حجم مقصد به‌صورت دستی ویرایش می‌کند. این امر بالقوه می‌تواند مشکل‌آفرین باشد، چرا که اگرچه کد در موارد آزمایش‌شده خاصی به درستی کار می‌کند، اما هیچ‌یک از این قالب‌های داده توسط مایکروسافت مستند نشده‌اند. پیش از بازنویسی این فایل، wimlib نسخه پیشین آن را در مسیر "\System Volume Information\WimOverlay.wimlib_backup" ذخیره می‌کند که در صورت نیاز می‌توانید آن را بازیابی کنید.
حتی اگر ایمیج WIM دارای برچسب «سازگار با WIMBoot» نباشد، همچنان می‌توانید استخراج با --wimboot را انجام دهید. این گزینه باعث می‌شود فایل‌های استخراج‌شده به‌صورت «پشتیبانی‌شده از خارج» (externally backed) توسط فایل WIM تنظیم شوند. درایور مایکروسافت که این سازوکار پشتیبانی خارجی را پیاده کرده است، ظاهراً به سازگار بودن یا نبودن ایمیج(ها) با WIMBoot اهمیتی نمی‌دهد. بنابراین، برچسب «WIMBoot-compatible» (تگ <WIMBOOT> در داده‌های XML) تنها به منزله نشان‌دهنده یک نیت کاری به نظر می‌رسد. افزون بر این، درایور مایکروسافت علاوه‌بر قطعات پیش‌فرض XPRESS با اندازه 4096 که هنگام اجرای wimcapture با گزینه --wimboot ساخته می‌شوند، می‌تواند فایل‌ها را از فایل‌های WIM با قطعات XPRESS با اندازه‌های 8192، 16384 و 32768 یا قطعات LZX با اندازه 32768 نیز به‌طور خارجی پشتیبانی کند.
تنها در ویندوز: در صورت امکان فایل‌های استخراج‌شده را با استفاده از فشرده‌سازی سیستم (System Compression) فشرده می‌کند. این گزینه تنها در ویندوز 10 یا جدیدتر، یا در نسخه‌های قدیمی‌تر ویندوز که درایور wofadk.sys مایکروسافت به آن‌ها افزوده شده، کار می‌کند. قالب‌های فشرده‌سازی گوناگونی را می‌توان با System Compression به کار برد، که یکی از آن‌ها باید در قالب FORMAT مشخص شود. گزینه‌ها عبارتند از: xpress4k، xpress8k، xpress16k و lzx.
استثناها درست مانند گزینه --wimboot مدیریت می‌شوند. به این معنی که: در صورت وجود، بخش [PrepopulateList] از فایل \Windows\System32\WimBootCompress.ini درون ایمیج WIM خوانده می‌شود و فایل‌های منطبق با هر یک از الگوهای این بخش فشرده نخواهند شد. علاوه بر این، wimlib فهرستی پیش‌فرض در خود دارد که جهت سازگاری با لودر بوت ویندوز، قالب فشرده‌سازی درخواست‌شده را برای فایل‌های درون آن نادیده می‌گیرد.
اگر فایلی آسیب دیده باشد (هش ذخیره‌شده آن با هش واقعی آن یکسان نباشد، یا بخش‌هایی از آن قابل بازگشایی نباشد)، به جای لغو کامل عملیات با یک خطا، فایل آسیب‌دیده را به همراه یک هشدار استخراج می‌کند. این گزینه می‌تواند برای بازیابی داده‌ها در صورت خرابی یک آرشیو WIM سودمند باشد. توجه داشته باشید که بازیابی داده‌ها همواره موفقیت‌آمیز نخواهد بود، چرا که به نوع و عمق خرابی رخ‌داده بستگی دارد..SH "نکات (NOTES)" یکپارچگی داده‌ها: فایل‌های WIM شامل جمع‌های کنترلی (checksums) داده‌های فایل هستند. برای تشخیص خرابی تصادفی (غیرعمدی) داده‌ها، wimlib جمع کنترلی هر فایلی را که استخراج می‌کند محاسبه کرده و در صورتی که با مقدار مورد انتظار مطابقت نداشته باشد خطایی صادر می‌کند، مگر اینکه گزینهٔ --recover-data داده شده باشد. (به نظر می‌رسد این رفتار پیش‌فرض معادل گزینهٔ /verify در ImageX است.) علاوه بر این، یک فایل WIM می‌تواند شامل یک جدول یکپارچگی (جمع‌های کنترلی اضافی) بر روی داده‌های خام کل فایل WIM باشد. به دلایل کارایی، wimlib به‌طور پیش‌فرض جدول یکپارچگی را بررسی نمی‌کند، اما می‌توان گزینهٔ --check را ارسال کرد تا این کار انجام شود.

فایل‌های ESD: ابزار wimlib می‌تواند فایل‌ها را از WIMهای فشرده‌شدهٔ یکپارچه (solid-compressed) یا فایل‌های "ESD" (با پسوند ‎.esd)، درست همانند فایل‌های عادی WIM (با پسوند ‎.wim) استخراج کند. با این حال، مایکروسافت گاهی فایل‌های ESD را با بخش‌های رمزگذاری‌شده توزیع می‌کند؛ wimlib نمی‌تواند چنین فایل‌هایی را تا زمانی که ابتدا رمزگشایی نشوند استخراج کند.

امنیت: ابزار wimlib با دقت نوشته شده است تا تمام ورودی‌ها را اعتبارسنجی کند و انتظار می‌رود در برابر برخی از انواع حملاتی که اغلب گریبان‌گیر سایر برنامه‌های آرشیو فایل می‌شوند، مانند حملات پیمایش دایرکتوری (directory traversal) (که بر حسب اتفاق، نرم‌افزار WIM مایکروسافت در برابر آن آسیب‌پذیر است) ایمن باشد. بخش‌های مهم wimlib، مانند خارج‌کننده‌ها از فشردگی (decompressors)، همچنین تحت آزمون فازینگ (fuzz testing) قرار گرفته‌اند. با این حال، wimlib در حال حاضر برای محافظت در برابر برخی انواع حملات محروم‌سازی از سرویس (DOS)، مانند اتمام حافظه یا «بمب‌های زیپ» (zip bombs)، طراحی نشده است.

استخراج اولین ایمیج از Windows PE WIM روی رسانهٔ نصب ویندوز در دایرکتوری "boot":

wimapply /mnt/windows/sources/boot.wim 1 boot

در ویندوز، اعمال یک ایمیج از یک حجم ذخیره‌سازی کامل، به عنوان مثال از "install.wim" که می‌توان آن را در رسانهٔ نصب ویندوز یافت:

wimapply install.wim 1 E:\

مشابه بالا، اما در حال اجرا بر روی یک سیستم شبه‌یونیکس (UNIX-like) که در آن پارتیشن مربوطه ‎/dev/sda2 است:

wimapply install.wim 1 /dev/sda2

توجه داشته باشید که پیش از اجرای هر یک از دستورات بالا، ممکن است نیاز باشد یک سیستم‌فایل NTFS روی پارتیشن ایجاد شود؛ به عنوان مثال با format.exe در ویندوز یا mkntfs(8) در سیستم‌های شبه‌یونیکس. به عنوان مثال، در یونیکس ممکن است این دستور را اجرا کنید:

mkntfs /dev/sda2 && wimapply install.wim 1 /dev/sda2

(البته اگر نمی‌خواهید تمام داده‌های موجود روی پارتیشن نابود شوند، این کار را انجام ندهید!)

برای نمونه‌هایی از اعمال WIMهای چندبخشی و قابل لوله‌کشی، به ترتیب بخش‌های SPLIT WIMS و PIPABLE WIMS را ببینید.

wimlib-imagex(1) wimcapture(1) wimextract(1) wiminfo(1)

January 2026 wimlib 1.14.5