قالب‌های Tar (Tar Formats)

کتابخانه libarchive(3) می‌تواند بیشتر بایگانی‌های tar را بخواند. این کتابخانه می‌تواند قالب‌های استاندارد POSIX با نام‌های “ustar” و “pax interchange” و همچنین قالب v7 tar و زیرمجموعه‌ای از قالب موروثی GNU tar را بنویسد.

تمامی قالب‌های tar هر مدخل را در یک یا چند رکورد ۵۱۲ بایتی ذخیره می‌کنند. نخستین رکورد برای فراداده‌های فایل، شامل نام فایل، برچسب زمان (timestamp) و اطلاعات حالت (mode) به کار می‌رود، و داده‌های فایل در رکوردهای بعدی ذخیره می‌شوند. گونه‌های بعدی این قالب، با تخصیص بخش‌های تعریف‌نشده از رکورد هدر، یا با گسترش هدر به چندین رکورد، یا با ذخیره مدخل‌های ویژه‌ای که تفسیر مدخل‌های بعدی را تغییر می‌دهند، آن را توسعه داده‌اند.

gnutar

کتابخانه libarchive(3) می‌تواند بیشتر بایگانی‌های tar در قالب GNU را بخواند. این کتابخانه در حال حاضر از پرکاربردترین افزونه‌های GNU پشتیبانی می‌کند، از جمله پشتیبانی مدرن از نام‌های فایل طولانی و نام‌های پیوند، و همچنین داده‌های atime و ctime. کتابخانه libarchive از بایگانی‌های چندجلدی (multi-volume) و نیز قالب قدیمی GNU برای نام‌های طولانی فایل پشتیبانی نمی‌کند. این کتابخانه می‌تواند مدخل‌های فایل تُنُک (sparse) در قالب GNU را بخواند، از جمله قالب‌های جدید مبتنی بر POSIX.

کتابخانه libarchive(3) می‌تواند قالب GNU tar را بنویسد، از جمله پشتیبانی از نام‌های طولانی فایل و نام‌های پیوند، و همچنین داده‌های atime و ctime.

pax

کتابخانه libarchive(3) می‌تواند بایگانی‌های قالب تبادل pax سازگار با POSIX را بخواند و بنویسد. بایگانی‌های قالب تبادل pax افزونه‌ای از قالب قدیمی‌تر ustar هستند که یک مدخل جداگانه با صفات اضافیِ ذخیره‌شده به صورت جفت‌های کلید/مقدار را بلافاصله پیش از هر مدخل عادی اضافه می‌کنند. حضور این مدخل‌های اضافی تنها تفاوت میان قالب تبادل pax و قالب قدیمی‌تر ustar است. صفات گسترش‌یافته دارای طول نامحدود بوده و به صورت رشته‌های یونیکد UTF-8 ذخیره می‌شوند. کلمات کلیدی تعریف‌شده در استاندارد همگی با حروف کوچک نوشته می‌شوند؛ به تولیدکنندگان اجازه داده شده است تا کلیدهای سفارشی خود را با افزودن نام تولیدکننده با حروف بزرگ در ابتدای آن‌ها تعریف نمایند. هنگام نوشتن بایگانی‌های pax، کتابخانه libarchive از بسیاری از کلیدهای SCHILY که توسط بایگانی‌ساز “star” اثر Joerg Schilling تعریف شده‌اند، و چند کلید LIBARCHIVE استفاده می‌کند. کتابخانه libarchive می‌تواند بیشتر کلیدهای SCHILY و بیشتر کلیدهای GNU معرفی‌شده توسط GNU tar را بخواند. این کتابخانه هر کلمه کلیدی را که متوجه نشود، بدون اخطار نادیده می‌گیرد.

قالب تبادل pax نام‌های فایل را به یونیکد تبدیل کرده و آن‌ها را با استفاده از کدگذاری UTF-8 ذخیره می‌کند. پیش از نسخه 3.0 کتابخانه libarchive، این کتابخانه به اشتباه فرض می‌کرد که توابع کار با نویسه‌های عریض (wide-character) سیستم به صورت بومی از یونیکد پشتیبانی می‌کنند. این امر باعث شد که در سیستم‌هایی که این فرض را برآورده نمی‌کردند، نام‌های فایل غیر ASCII به درستی پردازش نشوند.

restricted pax

کتابخانه libarchive همچنین می‌تواند بایگانی‌های pax را بنویسد که در آن‌ها تلاش می‌کند تا در صورت امکان از مدخل صفات گسترش‌یافته صرف‌نظر نماید. نتیجه با یک بایگانی ustar یکسان خواهد بود، مگر اینکه مدخل صفات گسترش‌یافته برای ذخیره یک نام فایل طولانی، نام پیوند طولانی، ACL گسترش‌یافته، پرچم‌های فایل، یا در صورتی که هر یک از داده‌های استاندارد ustar (نام کاربر، نام گروه، UID، GID و غیره) نتواند به طور کامل در هدر ustar نمایش داده شود، مورد نیاز باشد. در تمام حالات، نتیجه می‌تواند توسط هر برنامه‌ای که قادر به خواندن بایگانی‌های قالب تبادل pax سازگار با POSIX است، از حالت بایگانی خارج شود. برنامه‌هایی که قالب ustar را به درستی می‌خوانند (پایین را ببینید) نیز قادر به خواندن این قالب خواهند بود؛ هر صفت گسترش‌یافته‌ای به صورت فایل‌های جداگانه در دایرکتوری‌های PaxHeader استخراج خواهد شد.

ustar

کتابخانه libarchive می‌تواند این قالب را هم بخواند و هم بنویسد. این قالب دارای محدودیت‌های زیر است:

• شماره‌های اصلی (major) و فرعی (minor) دستگاه به ۲۱ بیت محدود شده‌اند. گره‌های با شماره‌های بزرگ‌تر به بایگانی اضافه نخواهند شد.
• نام‌های مسیر در بایگانی به ۲۵۵ بایت محدود شده‌اند. (اگر نویسه / دقیقاً در مکان مناسب نباشد، این مقدار کوتاه‌تر خواهد بود.)
• پیوندهای نمادین و پیوندهای سخت با نام فایل ارجاع‌شده در بایگانی ذخیره می‌شوند. این نام به ۱۰۰ بایت محدود شده است.
• صفات گسترش‌یافته، پرچم‌های فایل و سایر اطلاعات امنیتی گسترش‌یافته نمی‌توانند ذخیره شوند.
• مدخل‌های بایگانی به ۸ گیگابایت در اندازه محدود شده‌اند.

توجه داشته باشید که قالب تبادل pax هیچ یک از این محدودیت‌ها را ندارد. قالب ustar قدیمی است و به طور گسترده‌ای پشتیبانی می‌شود. استفاده از آن هنگامی توصیه می‌شود که سازگاری دغدغه اصلی باشد.

v7

کتابخانه libarchive می‌تواند قالب موروثی v7 tar را بخواند و بنویسد. این قالب دارای محدودیت‌های زیر است:

• تنها فایل‌های عادی، دایرکتوری‌ها و پیوندهای نمادین قابل بایگانی هستند. گره‌های دستگاه‌های بلوکی و نویسه‌ای، FIFOها و سوکت‌ها نمی‌توانند بایگانی شوند.
• نام‌های مسیر در بایگانی به ۱۰۰ بایت محدود شده‌اند.
• پیوندهای نمادین و پیوندهای سخت با نام فایل ارجاع‌شده در بایگانی ذخیره می‌شوند. این نام به ۱۰۰ بایت محدود شده است.
• اطلاعات کاربر و گروه به صورت شناسه‌های عددی ذخیره می‌شوند؛ هیچ امکانی برای ذخیره نام‌های کاربر یا گروه وجود ندارد.
• صفات گسترش‌یافته، پرچم‌های فایل و سایر اطلاعات امنیتی گسترش‌یافته نمی‌توانند ذخیره شوند.
• مدخل‌های بایگانی به ۸ گیگابایت در اندازه محدود شده‌اند.

به طور کلی، کاربران باید به دلیل قابلیت حمل، قالب ustar را ترجیح دهند، زیرا قالب v7 tar هم کاربرد کمتری دارد و هم قابلیت حمل کمتری فراهم می‌سازد.

کتابخانه libarchive همچنین مجموعه‌ای از افزونه‌های پرکاربرد برای قالب پایه tar را می‌خواند. این افزونه‌ها هر زمان که ظاهر شوند، به طور خودکار شناسایی می‌گردند.

افزونه‌های عددی (Numeric extensions)

استانداردهای POSIX نیازمند آن هستند که فیلدهای عددی با طول ثابت با موقعیت‌های نویسه‌ای رزروشده برای پایان‌دهنده‌ها نوشته شوند. کتابخانه Libarchive اجازه می‌دهد این فیلدها بدون نویسه‌های پایان‌دهنده نوشته شوند. این کار دامنه مجاز را گسترش می‌دهد؛ به ویژه، بایگانی‌های ustar با این افزونه می‌توانند مدخل‌هایی تا اندازه ۶۴ گیگابایت را پشتیبانی کنند. کتابخانه Libarchive همچنین مقادیر پایه ۲۵۶ (base-256) را در بیشتر فیلدهای عددی تشخیص می‌دهد. این ویژگی اساساً تمامی محدودیت‌ها را در زمینه اندازه فایل، زمان تغییر و شماره‌های دستگاه از میان برمی‌دارد.

افزونه‌های سولاریس (Solaris extensions)

کتابخانه Libarchive رکوردهای ACL و صفات گسترش‌یافته نوشته‌شده توسط Solaris tar را تشخیص می‌دهد.

نخستین برنامه tar در ویرایش هفتم یونیکس (Seventh Edition Unix) در سال ۱۹۷۹ ظاهر شد. نخستین استاندارد رسمی برای قالب فایل tar، قالب “ustar” (Unix Standard Tar) بود که توسط POSIX در سال ۱۹۸۸ تعریف گردید. استاندارد POSIX.1-2001 قالب ustar را برای ایجاد قالب “pax interchange” گسترش داد.

قالب‌های Cpio (Cpio Formats)

کتابخانه libarchive می‌تواند چندین گونه رایج از cpio را بخواند و بنویسد. یک بایگانی cpio هر مدخل را به صورت یک هدر با اندازه ثابت ذخیره می‌کند که به دنبال آن نام فایل با طول متغیر و داده‌های با طول متغیر قرار می‌گیرند. برخلاف قالب tar، قالب cpio تنها حداقل فاصله‌گذاری (padding) را برای هدر یا داده‌های فایل اعمال می‌کند. چندین گونه cpio وجود دارد که تفاوت عمده آن‌ها در شیوه ذخیره‌سازی هدر اولیه است: برخی مقادیر را به صورت اعداد مبنای هشت (اکتال) یا مبنای شانزده (هگزادسیمال) در اسکی ذخیره می‌کنند، و برخی دیگر به عنوان مقادیر دودویی با ترتیب بایت‌ها (byte order) و طول‌های متغیر.

binary

کتابخانه libarchive به طور شفاف هر دو گونه بزرگ‌پایان (big-endian) و کوچک‌پایان (little-endian) از دو قالب دودویی cpio را می‌خواند؛ قالب اولیه برگرفته از PWB/UNIX، و گونه متأخر که کاربرد گسترده‌تری دارد. این قالب از مقادیر دودویی ۳۲ بیتی برای اندازه فایل و mtime، و مقادیر دودویی ۱۶ بیتی برای سایر فیلدها استفاده می‌کرد. این قالب‌ها تنها از انواع فایل موجود در UNIX در زمان ایجادشان پشتیبانی می‌کنند. اندازه فایل‌ها در قالب PWB به دلیل محدودیت‌های سیستم پرونده به ۲۴ بیت محدود است، و در قالب دودویی جدیدتر، که در آن اعداد صحیح طولانی ۳۲ بیتی علامت‌دار استفاده می‌شد، به ۳۱ بیت محدود گردیده است.

odc

این قالب استانداردشده POSIX است که رسماً به عنوان “cpio interchange format” یا “octet-oriented cpio archive format” شناخته می‌شود و گاهی به طور غیررسمی با نام “old character format” از آن یاد می‌شود. این قالب محتویات هدر را به صورت مقادیر مبنای هشت در اسکی ذخیره می‌کند. این قالب استاندارد، قابل‌حمل و در برابر ابهام در ترتیب بایت‌ها مصون است. اندازه فایل و mtime به ۳۳ بیت (اندازه فایل ۸ گیگابایت) محدود شده‌اند و سایر فیلدها به ۱۸ بیت محدود هستند.

SVR4/newc

کتابخانه libarchive می‌تواند هر دو گونه CRCدار و بدون CRC از این قالب را بخواند. قالب SVR4 از مقادیر هگزادسیمال هشت‌رقمی برای تمامی فیلدهای هدر استفاده می‌کند. این امر اندازه فایل را به ۴ گیگابایت محدود کرده و همچنین mtime و سایر فیلدها را به ۳۲ بیت محدود می‌سازد. قالب SVR4 می‌تواند به صورت اختیاری شامل یک CRC از محتویات فایل باشد، هرچند libarchive در حال حاضر این CRC را بررسی و اعتبارسنجی نمی‌کند.

ابزار Cpio نخستین بار در PWB/UNIX 1.0 ظاهر شد که در سال ۱۹۷۷ در داخل AT&T منتشر گردید. نسخه PWB/UNIX 1.0 پایه و اساس System III Unix را تشکیل داد که در سال ۱۹۸۱ به بیرون از AT&T عرضه شد. این امر cpio را قدیمی‌تر از tar می‌سازد، اگرچه cpio در Version 7 AT&T Unix گنجانده نشده بود. در نتیجه، دستور tar در دانشگاه‌ها و گروه‌های پژوهشی که از نسخه ۷ استفاده می‌کردند بسیار شناخته‌شده‌تر شد. ترکیب ابزارهای find و cpio کنترل بسیار دقیقی بر انتخاب فایل فراهم می‌کرد. متأسفانه این قالب محدودیت‌های فراوانی دارد که آن را برای استفاده گسترده نامناسب می‌سازد. تنها قالب POSIX اجازه وجود فایل‌های بزرگ‌تر از ۴ گیگابایت را می‌دهد، و محدودیت ۱۸ بیتی آن برای اغلب فیلدهای دیگر، آن را برای سیستم‌های مدرن نامناسب می‌کند. علاوه بر این، قالب‌های cpio تنها مقادیر عددی UID/GID را ذخیره می‌کنند (نه نام‌های کاربری و نام‌های گروه)، که این موضوع می‌تواند انتقال صحیح بایگانی‌ها را میان سیستم‌هایی با شماره‌گذاری متفاوت کاربران بسیار دشوار سازد.

قالب‌های Shar (Shar Formats)

یک “بایگانی شل” (shell archive) یک اسکریپت شل است که هنگام اجرا بر روی یک سیستم سازگار با POSIX، مجموعه‌ای از اشیای سیستم پرونده را بازسازی می‌کند. کتابخانه libarchive می‌تواند دو نوع مختلف از بایگانی‌های shar را بنویسد:

shar

قالب سنتی shar از مجموعه محدودی از دستورات POSIX استفاده می‌کند، از جمله echo(1), mkdir(1), و sed(1). این قالب برای بایگانی قابل‌حمل مجموعه‌های کوچکی از فایل‌های متنی ساده مناسب است. با این حال، به طور کلی برای بایگانی‌های بزرگ مناسب نیست (بسیاری از پیاده‌سازی‌های sh(1) محدودیت‌هایی بر روی اندازه اسکریپت دارند) و همچنین نباید برای فایل‌های غیرمتنی به کار رود.

shardump

این قالب مشابه shar است اما فایل‌ها را با استفاده از uuencode(1) کدگذاری می‌کند تا نتیجه صرف‌نظر از محتویات فایل، یک فایل متنی ساده باشد. این قالب همچنین شامل دستورات شل اضافی است که تلاش می‌کنند تا حد امکان صفات بیشتری از فایل، از جمله مالک، حالت (mode) و پرچم‌ها را بازتولید نمایند. دستورات اضافی مورد استفاده برای بازگردانی صفات فایل، بایگانی‌های shardump را نسبت به بایگانی‌های ساده shar کم‌تر قابل‌حمل می‌سازد.

قالب ISO9660 (ISO9660 format)

کتابخانه Libarchive می‌تواند فایل‌های حاوی ایمیج‌های CDROM سازگار با ISO9660 را بخواند و استخراج کند. در بسیاری از موارد، این قابلیت نیاز به سوزاندن (رایت) یک CDROM فیزیکی را تنها برای خواندن فایل‌های درون یک ایمیج ISO9660 برطرف می‌کند. این امر همچنین از مسائل امنیتی و پیچیدگی‌های مربوط به سوار کردن‌های مجازی (virtual mounts) و دستگاه‌های loopback جلوگیری می‌نماید. کتابخانه Libarchive از رایج‌ترین افزونه‌های Rockridge پشتیبانی کرده و پشتیبانی جزئی از افزونه‌های Joliet دارد. در صورت وجود هر دو افزونه، افزونه‌های Joliet استفاده خواهند شد و از افزونه‌های Rockridge صرف‌نظر می‌شود. به ویژه، این امر می‌تواند در مورد پیوندهای سخت و پیوندهای نمادین، که توسط Rockridge پشتیبانی می‌شوند اما توسط Joliet پشتیبانی نمی‌شوند، مشکلاتی ایجاد کند.

کتابخانه Libarchive ایمیج‌های ISO9660 را با استفاده از یک راهبرد جریانی (streaming) می‌خواند. این ویژگی به آن امکان می‌دهد تا ایمیج‌های فشرده‌شده را مستقیماً بخواند (فشرده‌زدایی در لحظه) و اجازه می‌دهد ایمیج‌ها را مستقیماً از سوکت‌های شبکه، لوله‌ها (pipes) و سایر منابع داده بدون قابلیت جستجو (non-seekable) بخواند. این راهبرد برای ایمیج‌های بهینه‌سازی‌شده ISO9660 ایجادشده توسط بسیاری از برنامه‌های محبوب به خوبی کار می‌کند. چنین برنامه‌هایی تمامی اطلاعات دایرکتوری را در ابتدای ایمیج ISO9660 جمع‌آوری می‌کنند تا بتوان آن را با حداقل جستجو و جابجایی هد (seeking) از یک دیسک فیزیکی خواند. با این حال، همه ایمیج‌های ISO9660 را نمی‌توان به این شیوه خواند.

کتابخانه Libarchive همچنین می‌تواند ایمیج‌های ISO9660 را بنویسد. چنین ایمیج‌هایی کاملاً بهینه‌سازی شده‌اند و اطلاعات دایرکتوری پیش از تمام داده‌های فایل قرار می‌گیرد. این کار با ذخیره تمام داده‌های فایل در یک فایل موقت در حین جمع‌آوری اطلاعات دایرکتوری در حافظه انجام می‌شود. هنگامی که ایجاد ایمیج به پایان رسید، libarchive ساختار دایرکتوری را می‌نویسد و به دنبال آن داده‌های فایل نوشته می‌شوند. مکان مورد استفاده برای فایل موقت را می‌توان با متغیرهای محیطی معمول تغییر داد.

قالب Zip (Zip format)

کتابخانه Libarchive می‌تواند بایگانی‌های قالب zip را که دارای مدخل‌های فشرده‌نشده و مدخل‌های فشرده‌شده با الگوریتم‌های “deflate”, “LZMA”, “XZ”, “BZIP2” و “ZSTD” هستند، بخواند و بنویسد. کتابخانه Libarchive همچنین می‌تواند بایگانی‌های قالب zip با مدخل‌های فشرده‌شده با الگوریتم “PPMd” را بخواند، اما نمی‌تواند بنویسد. سایر الگوریتم‌های فشرده‌سازی zip پشتیبانی نمی‌شوند. افزونه‌های پشتیبانی‌شده توسط libarchive عبارتند از Zip64، افزونه‌های libarchive برای پشتیبانی بهتر از جریان‌سازی، رمزنگاری سنتی ZIP در PKZIP، فیلدهای اضافی یونیکس در Info-ZIP، زمان اضافی و مسیر یونیکد، و نیز رمزنگاری AES در WinZIP. این کتابخانه می‌تواند بایگانی‌های jar، افزونه شاخه‌های منابع (resource forks) با نام __MACOSX برای OS X و بایگانی‌های خوداستخراج‌گر (self-extracting) zip را استخراج کند. کتابخانه Libarchive می‌تواند از هر یک از دو راهبرد مختلف برای خواندن بایگانی‌های Zip استفاده کند: یک راهبرد جریانی (streaming) که سریع است و می‌تواند بایگانی‌های بسیار بزرگ را مدیریت کند، و یک راهبرد جستجوگر (seeking) که می‌تواند بایگانی‌های خوداستخراج‌گر Zip و بایگانی‌های دارای اعضای حذف‌شده یا سایر تغییرات درجا را به درستی پردازش نماید.

خواننده جریانی، بایگانی‌های Zip را همزمان با خوانده شدن پردازش می‌کند. این خواننده می‌تواند بایگانی‌هایی با اندازه دلخواه را از نوار یا سوکت‌های شبکه بخواند، و می‌تواند بایگانی‌های Zip را که به طور جداگانه فشرده یا کدگذاری شده‌اند رمزگشایی نماید. با این حال، بایگانی‌های خوداستخراج‌گر Zip و بایگانی‌های با انواع خاصی از تغییرات را نمی‌توان با این روش به درستی مدیریت کرد. چنین بایگانی‌هایی نیازمند آن هستند که خواننده ابتدا دایرکتوری مرکزی (Central Directory) را پردازش کند که معمولاً در انتهای یک بایگانی Zip قرار دارد و بنابراین برای خواننده جریانی غیرقابل دسترس است. اگر برنامه‌ای که از libarchive استفاده می‌کند پشتیبانی از جستجو (seek) را فعال کرده باشد، آنگاه libarchive از این قابلیت برای پردازش اولیه دایرکتوری مرکزی استفاده خواهد کرد.

به ویژه، خواننده جستجوگر باید برای مدیریت صحیح بایگانی‌های خوداستخراج‌گر استفاده شود. چنین بایگانی‌هایی شامل یک برنامه و به دنبال آن یک بایگانی عادی Zip هستند. خواننده جریانی نمی‌تواند بخش آغازین برنامه را تجزیه کند، اما خواننده جستجوگر کار خود را با خواندن دایرکتوری مرکزی از انتهای بایگانی آغاز می‌کند. به همین ترتیب، بایگانی‌های Zip که درجا ویرایش شده‌اند ممکن است دارای مدخل‌های حذف‌شده یا سایر داده‌های زائد باشند که تنها با خواندن اولیه دایرکتوری مرکزی می‌توان آن‌ها را به دقت تشخیص داد.

قالب پرونده بایگانی (کتابخانه) (Archive (library) file format)

قالب بایگانی یونیکس (که معمولاً توسط بایگانی‌ساز ar(1) ایجاد می‌شود) یک قالب چندمنظوره است که تقریباً به طور انحصاری برای فایل‌های شیء (object files) جهت خوانده شدن توسط ویرایشگر پیوند (link editor) ld(1) استفاده می‌شود. قالب ar هرگز استانداردسازی نشده است. دو گونه رایج از آن وجود دارد: قالب GNU که از SVR4 مشتق شده است، و قالب BSD که نخستین بار در 4.4BSD ظاهر شد. این دو در درجه اول در نحوه مدیریت نام‌های فایل طولانی‌تر از ۱۵ نویسه با یکدیگر تفاوت دارند: گونه GNU/SVR4 جدول نام‌های فایل را در ابتدای بایگانی می‌نویسد؛ قالب BSD هر نام فایل طولانی را در یک ناحیه افزونه در مجاورت مدخل ذخیره می‌کند. کتابخانه Libarchive می‌تواند هر دو افزونه را بخواند، از جمله بایگانی‌هایی که ممکن است شامل هر دو نوع نام‌های طولانی فایل باشند. برنامه‌هایی که از libarchive استفاده می‌کنند می‌توانند قالب GNU/SVR4 را بنویسند اگر مدخلی با نام // حاوی یک جدول نام فایل ارائه دهند تا پیش از هر یک از مدخل‌ها در بایگانی نوشته شود. هر مدخلی که نام آن در جدول نام فایل نباشد، با استفاده از نام‌های طولانی به سبک BSD نوشته خواهد شد. این موضوع می‌تواند برای برنامه‌هایی مانند GNU ld که از نام‌های طولانی فایل به سبک BSD پشتیبانی نمی‌کنند، مشکلاتی ایجاد کند.

قالب mtree (mtree)

کتابخانه Libarchive می‌تواند فایل‌ها را در قالب mtree(5) بخواند و بنویسد. این قالب یک قالب بایگانی واقعی نیست، بلکه یک توصیف متنی از یک سلسله‌مراتب فایل است که در آن هر خط نام یک فایل را مشخص کرده و فراداده‌های معینی را درباره آن فایل ارائه می‌دهد. کتابخانه Libarchive می‌تواند تمامی کلمات کلیدی پشتیبانی‌شده توسط هر دو نسخه NetBSD و FreeBSD از mtree(8) را بخواند، هرچند بسیاری از کلمات کلیدی در حال حاضر نمی‌توانند در یک شیء archive_entry ذخیره شوند. هنگام نوشتن، libarchive از استفاده از رابط archive_write_set_options(3) برای مشخص کردن اینکه کدام کلمات کلیدی باید در خروجی گنجانده شوند پشتیبانی می‌کند. اگر libarchive با دسترسی به کتابخانه‌های رمزنگاری مناسب (مانند کتابخانه‌های OpenSSL) کامپایل شده باشد، می‌تواند مدخل‌های هش نظیر sha512 یا md5 را از داده‌های فایلی که به نویسنده mtree تحویل داده می‌شود محاسبه نماید.

هنگام خواندن یک فایل mtree، کتابخانه libarchive فایل‌های متناظر را با استفاده از کلمه کلیدی contents در صورت وجود، یا با نام معمول فایل روی دیسک پیدا می‌کند. اگر بتواند فایل را روی دیسک پیدا کرده و باز کند، از آن برای تکمیل هرگونه فراداده ناموجود در فایل mtree استفاده خواهد کرد و محتویات فایل را خوانده و به برنامه استفاده‌کننده از libarchive تحویل می‌دهد. اگر نتواند فایل را روی دیسک پیدا کرده و باز کند، libarchive برای هرگونه تلاش به منظور خواندن بدنه مدخل، خطایی برمی‌گرداند.

قالب 7-Zip (7-Zip)

کتابخانه Libarchive می‌تواند بایگانی‌های قالب 7-Zip را بخواند و بنویسد. TODO: اطلاعات بیشتری نیاز است

قالب CAB (CAB)

کتابخانه Libarchive می‌تواند بایگانی‌های قالب Microsoft Cabinet ( “CAB”) را بخواند. TODO: اطلاعات بیشتری نیاز است.

قالب LHA (LHA)

TODO: اطلاعات درباره پشتیبانی libarchive از LHA

قالب RAR (RAR)

کتابخانه Libarchive پشتیبانی محدودی از خواندن بایگانی‌های قالب RAR دارد. در حال حاضر، libarchive می‌تواند بایگانی‌های قالب RARv3 را که یا به صورت فشرده‌نشده ایجاد شده‌اند، یا با استفاده از هر یک از روش‌های فشرده‌سازی پشتیبانی‌شده توسط قالب RARv3 فشرده شده‌اند، بخواند. کتابخانه Libarchive همچنین می‌تواند بایگانی‌های خوداستخراج‌گر RAR را بخواند.

قالب Warc (Warc)

کتابخانه Libarchive می‌تواند “بایگانی‌های وب” را بخواند و بنویسد. TODO: اطلاعات بیشتری نیاز است

قالب XAR (XAR)

کتابخانه Libarchive می‌تواند قالب XAR مورد استفاده توسط بسیاری از ابزارهای Apple را بخواند و بنویسد. TODO: اطلاعات بیشتری نیاز است