قالب کلی (General Format)

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

به منظور سازگاری با گرداننده‌های نواری که از اندازه‌های بلوک ثابت استفاده می‌کنند، برنامه‌های خواننده یا نویسنده فایل‌های tar همیشه در هر عملیات ورودی/خروجی (I/O) تعداد ثابتی رکورد را می‌خوانند یا می‌نویسند. این “بلوک‌ها” همواره مضربی از اندازه رکورد هستند. حداکثر اندازه بلوک پشتیبانی‌شده در پیاده‌سازی‌های اولیه ۱۰۲۴۰ بایت یا ۲۰ رکورد بود. این مقدار همچنان در بیشتر پیاده‌سازی‌ها حالت پیش‌فرض است، اگرچه امروزه در درایوهای نوار پرسرعت مدرن معمولاً اندازه‌های بلوک ۱ مبی‌بایت (۲۰۴۸ رکورد) یا بزرگ‌تر به کار می‌روند. (توجه: اصطلاحات “بلوک” و “رکورد” در اینجا کاملاً استاندارد نیستند؛ این سند از قرارداد وضع‌شده توسط John Gilmore در مستندسازی pdtar پیروی می‌کند.)

قالب بایگانی سبک قدیم (Old-Style Archive Format)

قالب سنتی بایگانی tar بارها گسترش یافته است تا اطلاعات تکمیلی مورد نیاز پیاده‌سازان مختلف را در بر گیرد. این بخش گونه‌ای را شرح می‌دهد که توسط دستور tar در Version 7 AT&T UNIX پیاده‌سازی شده بود و به نظر می‌رسد نخستین نسخه پرکاربرد برنامه tar باشد.

رکورد هدر برای یک بایگانی tar به سبک قدیم از ساختار زیر تشکیل شده است:

struct header_old_tar {
	char name[100];
	char mode[8];
	char uid[8];
	char gid[8];
	char size[12];
	char mtime[12];
	char checksum[8];
	char linkflag[1];
	char linkname[100];
	char pad[255];
};

name

نام مسیر، ذخیره‌شده به عنوان یک رشته منتهی به تهی (null-terminated). پیاده‌سازی‌های اولیه tar تنها فایل‌های عادی (شامل پیوندهای سخت به آن فایل‌ها) را ذخیره می‌کردند. یک قرارداد رایج اولیه، استفاده از نویسه اسلش پایانی "/" برای مشخص کردن نام دایرکتوری بود که امکان بایگانی و بازیابی مجوزها و اطلاعات مالک دایرکتوری را فراهم می‌کرد.

mode

حالت (mode) فایل، ذخیره‌شده به عنوان عدد در مبنای هشت (اکتال) در قالب اسکی.

uid, gid

شناسه کاربر و شناسه گروه مالک فایل، به صورت اعداد مبنای هشت در قالب اسکی.

size

اندازه فایل، به صورت عدد مبنای هشت در قالب اسکی. تنها برای فایل‌های عادی، این فیلد نمایانگر مقدار داده‌ای است که پس از هدر قرار دارد. به ویژه، این فیلد در پیاده‌سازی‌های اولیه tar هنگام استخراج پیوندهای سخت نادیده گرفته می‌شد. برنامه‌های نویسنده مدرن باید همیشه برای مدخل‌های پیوند سخت اندازه صفر را ذخیره کنند.

mtime

زمان آخرین تغییر فایل، به صورت عدد مبنای هشت در قالب اسکی. این فیلد تعداد ثانیه‌های سپری‌شده از مبدأ زمانی یونیکس (Epoch)، یعنی ساعت 00:00:00 UTC در ۱ ژانویه ۱۹۷۰ را مشخص می‌کند. توجه داشته باشید که باید از مقادیر منفی در اینجا اجتناب شود، زیرا رفتار هماهنگی در پردازش آن‌ها وجود ندارد.

checksum

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

linkflag, linkname

به منظور حفظ پیوندهای سخت و صرفه‌جویی در فضای نوار، فایلی که دارای پیوندهای متعدد است فقط در نخستین مواجهه در بایگانی نوشته می‌شود. در دفعات بعدی مواجهه، فیلد linkflag روی نویسه اسکی ‘1’ تنظیم شده و فیلد linkname نخستین نامی را که فایل تحت آن ظاهر شده نگهداری می‌کند. (توجه داشته باشید که فایل‌های عادی دارای مقدار تهی در فیلد linkflag هستند.)

پیاده‌سازی‌های اولیه tar در نحوه خاتمه دادن به این فیلدها تفاوت‌هایی داشتند. دستور tar در Version 7 AT&T UNIX از قراردادهای زیر استفاده می‌کرد (این موضوع در صفحات راهنمای اولیه BSD نیز مستند شده است): نام مسیر باید به بایت تهی ختم شود؛ فیلدهای mode، uid و gid باید به یک فاصله و یک بایت تهی ختم شوند؛ فیلدهای size و mtime باید به یک فاصله ختم شوند؛ چک‌سام به یک بایت تهی و یک فاصله ختم می‌شود. پیاده‌سازی‌های اولیه فیلدهای عددی را با فاصله‌های پیشرو (leading spaces) پر می‌کردند. به نظر می‌رسد این یک رویه معمول تا زمان انتشار استاندارد IEEE Std 1003.1-1988 (“POSIX.1”) بوده است. برای حفظ حداکثر سازگاری و قابلیت حمل، پیاده‌سازی‌های مدرن باید فیلدهای عددی را با صفرهای پیشرو پر کنند.

بایگانی‌های پیش از پازیکس (Pre-POSIX Archives)

پیش‌نویس اولیه‌ای از استاندارد IEEE Std 1003.1-1988 (“POSIX.1”) به عنوان پایه‌ای برای برنامه pdtar نوشته John Gilmore و بسیاری از پیاده‌سازی‌های سیستمی در اواخر دهه ۱۹۸۰ و اوایل دهه ۱۹۹۰ عمل کرد. این بایگانی‌ها به طور کلی از قالب POSIX ustar شرح‌داده‌شده در زیر با تفاوت‌های زیر پیروی می‌کنند:

• مقدار جادویی (magic) شامل پنج نویسه “ustar” است که پس از آن یک نویسه فاصله قرار دارد. فیلد نسخه (version) شامل یک نویسه فاصله و به دنبال آن یک بایت تهی است.
• فیلدهای عددی معمولاً با فاصله‌های پیشرو پر می‌شوند (نه با صفرهای پیشرو طبق توصیه استاندارد نهایی).
• فیلد پیشوند (prefix) اغلب استفاده نمی‌شود و طول نام مسیرها را به ۱۰۰ نویسه همانند بایگانی‌های سبک قدیم محدود می‌کند.

بایگانی‌های POSIX ustar (POSIX ustar Archives)

استاندارد IEEE Std 1003.1-1988 (“POSIX.1”) یک قالب فایل استاندارد tar را تعریف کرد تا توسط پیاده‌سازی‌های منطبق با tar(1) خوانده و نوشته شود. این قالب اغلب پس از مقدار جادویی به‌کاررفته در هدر، قالب “ustar” نامیده می‌شود. (این نام کوته‌نوشتی از “Unix Standard TAR” است.) این استاندارد، قالب تاریخی را با فیلدهای جدیدی گسترش می‌دهد:

struct header_posix_ustar {
	char name[100];
	char mode[8];
	char uid[8];
	char gid[8];
	char size[12];
	char mtime[12];
	char checksum[8];
	char typeflag[1];
	char linkname[100];
	char magic[6];
	char version[2];
	char uname[32];
	char gname[32];
	char devmajor[8];
	char devminor[8];
	char prefix[155];
	char pad[12];
};

typeflag

نوع مدخل. استاندارد POSIX فیلد قبلی linkflag را با چندین مقدار نوع جدید گسترش داد:

“0”

فایل عادی. جهت سازگاری، با NUL باید به عنوان مترادف رفتار شود.

“1”

پیوند سخت.

“2”

پیوند نمادین.

“3”

گره دستگاه کاراکتری.

“4”

گره دستگاه بلوکی.

“5”

دایرکتوری.

“6”

گره FIFO (لوله نام‌گذاری‌شده).

“7”

رزرو شده.

Other

یک پیاده‌سازی منطبق با POSIX باید با هر مقدار ناشناخته typeflag مانند یک فایل عادی رفتار کند. به ویژه، برنامه‌های نویسنده باید اطمینان حاصل کنند که تمام مدخل‌ها نام فایل معتبری دارند تا بتوانند توسط برنامه‌های خواننده‌ای که از پسوند مربوطه پشتیبانی نمی‌کنند نیز بازیابی شوند. حروف بزرگ "A" تا "Z" برای پسوندهای سفارشی رزرو شده‌اند. توجه داشته باشید که سوکت‌ها (sockets) و مدخل‌های whiteout قابل بایگانی نیستند.

شایان ذکر است که فیلد size به طور ویژه بسته به نوع مدخل دارای معانی متفاوتی است. برای فایل‌های عادی، مسلماً این فیلد مقدار داده‌ای را نشان می‌دهد که پس از هدر می‌آید. برای دایرکتوری‌ها، ممکن است برای نشان دادن اندازه کل تمام فایل‌های موجود در دایرکتوری استفاده شود تا توسط سیستم‌عامل‌هایی که فضای دایرکتوری را از پیش تخصیص می‌دهند به کار رود. برای تمامی انواع دیگر، باید توسط برنامه‌های نویسنده روی صفر تنظیم شده و توسط برنامه‌های خواننده نادیده گرفته شود.

magic

شامل مقدار جادویی “ustar” به همراه یک بایت NUL برای نشان دادن این است که این یک بایگانی استاندارد POSIX است. انطباق کامل مستلزم مقداردهی صحیح فیلدهای uname و gname است.

version

نسخه. این مقدار برای بایگانی‌های استاندارد POSIX باید “00” (دو نسخه از رقم صفر اسکی) باشد.

uname, gname

نام‌های کاربر و گروه به عنوان رشته‌های اسکی منتهی به تهی. این نام‌ها در صورت تنظیم بودن و وجود نام‌های متناظر در سیستم، باید نسبت به مقادیر uid/gid در اولویت قرار گیرند.

devmajor, devminor

شماره‌های اصلی (major) و فرعی (minor) برای مدخل‌های دستگاه کاراکتری یا دستگاه بلوکی.

name, prefix

اگر نام مسیر برای جا شدن در ۱۰۰ بایت ارائه‌شده در قالب استاندارد بیش از حد طولانی باشد، می‌توان آن را در هر نویسه / شکست، به گونه‌ای که بخش نخست درون فیلد prefix قرار گیرد. اگر فیلد prefix خالی نباشد، برنامه خواننده مقدار prefix و یک نویسه / را به ابتدای فیلد نام عادی اضافه می‌کند تا نام مسیر کامل به دست آید. استاندارد نیازی به وجود نویسه پایانی / در نام دایرکتوری‌ها ندارد، هرچند بیشتر پیاده‌سازی‌ها همچنان به دلایل سازگاری آن را درج می‌کنند.

توجه داشته باشید که تمام بایت‌های استفاده‌نشده باید روی NUL تنظیم شوند.

پایان فیلدها در POSIX اندکی متفاوت از پیاده‌سازی‌های پیشین مشخص شده است. فیلدهای magic, uname و gname باید دارای یک بایت پایانی NUL باشند. فیلدهای pathname, linkname و prefix باید دارای یک بایت پایانی NUL باشند مگر اینکه کل فیلد را پر کرده باشند. (به ویژه، ذخیره یک نام مسیر ۲۵۶ نویسه‌ای امکان‌پذیر است اگر نویسه ۱۵۶ام آن تصادفاً یک / باشد.) استاندارد POSIX نیازمند آن است که فیلدهای عددی با صفر در ابتدا پر شوند و پایان آن‌ها با نویسه‌های فاصله یا NUL مشخص گردد.

در حال حاضر بیشتر پیاده‌سازی‌های tar با قالب ustar مطابقت دارند و گاهی آن را با افزودن فیلدهای جدید به فضای خالی انتهای رکورد هدر گسترش می‌دهند.

پسوندهای عددی (Numeric Extensions)

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

یک راهکار بدیهی برای افزایش اندازه فایل‌ها، حذف نویسه‌های پایان‌دهنده از فیلدهای عددی گوناگون است. به عنوان نمونه، استاندارد تنها اجازه می‌دهد فیلد size شامل ۱۱ رقم در مبنای هشت باشد و بایت دوازدهم را برای نویسه پایانی NUL رزرو می‌کند. اجازه دادن به ۱۲ رقم در مبنای هشت، امکان ذخیره فایل‌هایی تا اندازه ۶۴ گیگابایت را فراهم می‌سازد.

پسوند دیگر که توسط GNU tar، star و سایر پیاده‌سازی‌های جدیدتر tar به کار گرفته شده است، استفاده از اعداد دودویی (باینری) در فیلدهای عددی استاندارد را ممکن می‌سازد. این حالت با تنظیم بیت بالای بایت اول مشخص می‌شود. باقی‌مانده فیلد به عنوان یک مقدار علامت‌دار متمم دو (twos-complement) پردازش می‌گردد. این شیوه مقادیر ۹۵ بیتی را برای فیلدهای طول و زمان، و مقادیر ۶۳ بیتی را برای شماره‌های uid، gid و دستگاه فراهم می‌سازد. به ویژه، این روش راهکاری هماهنگ برای مدیریت مقادیر زمانی منفی ارائه می‌دهد. ابزار GNU tar از این پسوند برای فیلدهای length، mtime، ctime و atime پشتیبانی می‌کند. برنامه star نوشته Joerg Schilling و کتابخانه libarchive از این پسوند برای تمامی فیلدهای عددی پشتیبانی می‌نمایند. توجه داشته باشید که این پسوند تا حد زیادی با رکورد ویژگی‌های گسترش‌یافته ارائه‌شده در قالب تبادل pax منسوخ شده است.

یکی دیگر از پسوندهای اولیه GNU، اجازه استفاده از مقادیر base-64 را به جای مبنای هشت می‌داد. این پسوند عمر کوتاهی داشت و امروزه دیگر توسط هیچ پیاده‌سازی پشتیبانی نمی‌شود.

قالب تبادل پکس (Pax Interchange Format)

ویژگی‌های بسیاری وجود دارند که نمی‌توان آن‌ها را به صورت قابل حمل در یک بایگانی POSIX ustar ذخیره کرد. استاندارد IEEE Std 1003.1-2001 (“POSIX.1”) یک “قالب تبادل pax” را تعریف کرد که از دو نوع مدخل جدید برای نگهداری فراداده‌های متنی که بر مدخل‌های بعدی اعمال می‌شوند، استفاده می‌کند. توجه داشته باشید که یک بایگانی با قالب تبادل pax از هر نظر یک بایگانی ustar محسوب می‌شود. داده‌های جدید در مدخل‌های بایگانی سازگار با ustar ذخیره می‌شوند که از typeflag با مقدار “x” یا “g” استفاده می‌نمایند. به ویژه، پیاده‌سازی‌های قدیمی‌تر که به طور کامل از این پسوندها پشتیبانی نمی‌کنند، فراداده‌ها را درون فایل‌های عادی استخراج می‌کنند که در آنجا می‌توان در صورت نیاز آن‌ها را بررسی کرد.

یک مدخل در بایگانی با قالب تبادل pax از یک یا دو مدخل استاندارد ustar تشکیل می‌شود که هر کدام هدر و داده‌های خود را دارند. نخستین مدخل اختیاری، ویژگی‌های گسترش‌یافته را برای مدخل بعدی ذخیره می‌کند. این مدخل اختیاری دارای typeflag با مقدار "x" و یک فیلد size است که اندازه کل ویژگی‌های گسترش‌یافته را نشان می‌دهد. خودِ ویژگی‌های گسترش‌یافته به صورت مجموعه‌ای از خطوط متنی با کدبندی قابل حمل UTF-8 ذخیره می‌شوند. هر خط شامل یک عدد در مبنای ده (ده‌دهی)، یک فاصله، یک رشته کلید (key)، یک علامت مساوی، یک رشته مقدار (value) و یک خط جدید است. عدد ده‌دهی طول کل خط را شامل فیلد طول اولیه و خط جدید پایانی مشخص می‌کند. نمونه‌ای از چنین فیلدی به صورت زیر است:

atime, ctime, mtime

زمان‌های دسترسی به فایل، تغییر اینود (inode) و آخرین تغییر در محتوای فایل. این فیلدها می‌توانند منفی باشند یا شامل ممیز اعشاری و مقادیر کسری باشند.

hdrcharset

مجموعه نویسه‌های به‌کاررفته در مقادیر پسوند pax. به طور پیش‌فرض، فرض می‌شود که تمام مقادیر متنی در ویژگی‌های گسترش‌یافته pax در قالب UTF-8 هستند، از جمله نام مسیرها، نام‌های کاربری و نام‌های گروه. در برخی موارد، ترجمه قراردادهای محلی به UTF-8 امکان‌پذیر نیست. اگر این کلید وجود داشته باشد و مقدار آن رشته اسکی شش‌نویسه‌ای “BINARY” باشد، آنگاه تمام مقادیر متنی در یک کدبندی چندبایتی وابسته به پلتفرم فرض می‌شوند. توجه داشته باشید که تنها دو مقدار معتبر برای این کلید وجود دارد: “BINARY” یا “ISO-IR 10646 2000 UTF-8”. هیچ مقدار دیگری توسط استاندارد مجاز دانسته نشده است، و از مقدار دوم عموماً نباید استفاده شود زیرا در صورت عدم تعیین این کلید، همان حالت پیش‌فرض است. به ویژه، این پرچم نباید به عنوان یک سازوکار عمومی برای مجاز ساختن ذخیره نام فایل‌ها در کدبندی‌های دلخواه به کار رود.

uname, uid, gname, gid

نام کاربر، نام گروه، و مقادیر عددی UID و GID. نام کاربری و نام گروه ذخیره‌شده در اینجا با UTF-8 کدگذاری می‌شوند و بنابراین می‌توانند شامل نویسه‌های غیر اسکی باشند. فیلدهای UID و GID می‌توانند طولی دلخواه داشته باشند.

linkpath

مسیر کامل فایلی که به آن پیوند داده شده است. توجه داشته باشید که این مقدار با UTF-8 کدگذاری می‌شود و می‌تواند شامل نویسه‌های غیر اسکی باشد.

path

نام مسیر کامل مدخل. توجه داشته باشید که این مقدار با UTF-8 کدگذاری می‌شود و می‌تواند شامل نویسه‌های غیر اسکی باشد.

realtime.*, security.*

این کلیدها رزرو شده‌اند و ممکن است برای استانداردسازی‌های آینده به کار روند.

size

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

SCHILY.*

ویژگی‌های اختصاصی توسعه‌دهنده که توسط پیاده‌سازی star نوشته Joerg Schilling به کار می‌روند.

SCHILY.acl.access, SCHILY.acl.default, SCHILY.acl.ace

لیست‌های دسترسی، پیش‌فرض و ACLهای NFSv4 را به عنوان رشته‌های متنی در قالبی ذخیره می‌کند که پسوندی از قالب مشخص‌شده در پیش‌نویس ۱۷ استاندارد POSIX.1e است. به ویژه، هر مشخصه دسترسی کاربر یا گروه می‌تواند شامل یک فیلد اضافی جداشده با دونقطه به همراه UID یا GID عددی باشد. این امر امکان بازیابی ACLها را در سیستم‌هایی که ممکن است اطلاعات کامل کاربر یا گروه را در دسترس نداشته باشند (مانند زمان‌هایی که سرویس‌های NIS/YP یا LDAP موقتاً قطع هستند) فراهم می‌سازد.

SCHILY.devminor, SCHILY.devmajor

شماره‌های کامل فرعی و اصلی برای گره‌های دستگاه.

SCHILY.fflags

پرچم‌های فایل (File flags).

SCHILY.realsize

اندازه کامل فایل بر روی دیسک.

SCHILY.dev, SCHILY.ino, SCHILY.nlinks

شماره دستگاه، شماره اینود و تعداد پیوندها برای مدخل. به ویژه، توجه داشته باشید که یک بایگانی با قالب تبادل pax که از پسوندهای SCHILY.* نوشته Joerg Schilling استفاده می‌کند، می‌تواند تمامی داده‌های موجود در struct stat را ذخیره نماید.

LIBARCHIVE.*

ویژگی‌های اختصاصی توسعه‌دهنده که توسط کتابخانه libarchive و برنامه‌های استفاده‌کننده از آن به کار می‌روند.

LIBARCHIVE.creationtime

زمان ایجاد فایل. (این مورد نباید با ویژگی POSIX “ctime” اشتباه گرفته شود که به زمان آخرین تغییر در فراداده‌های فایل اشاره دارد.)

LIBARCHIVE.xattr.namespace.key

کتابخانه libarchive ویژگی‌های گسترش‌یافته به سبک POSIX.1e را با استفاده از کلیدهایی به این فرم ذخیره می‌کند. مقدار key به صورت URL کدگذاری می‌شود (URL-encoded): تمام نویسه‌های غیر اسکی و دو نویسه ویژه “=” و “%” به صورت “%” و به دنبال آن دو رقم هگزادسیمال با حروف بزرگ کدگذاری می‌شوند. مقدار این کلید، مقدار ویژگی گسترش‌یافته کدگذاری‌شده در قالب base 64 است.

VENDOR.*

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

هر مقداری که در یک ویژگی گسترش‌یافته ذخیره شده باشد، بر مقادیر متناظر در هدر استاندارد tar اولویت داشته و جایگزین آن می‌شود. توجه داشته باشید که برنامه‌های خواننده منطبق با استاندارد باید در صورت جایگزینی، فیلدهای عادی را نادیده بگیرند. این امر مهم است، زیرا برنامه‌های بایگانی‌کننده موجود در این شرایط مقادیر نامنطبق با استاندارد را در فیلدهای هدر استاندارد ذخیره می‌کنند. هیچ محدودیتی در طول برای هیچ‌یک از این فیلدها وجود ندارد. به ویژه، فیلدهای عددی می‌توانند به دلخواه بزرگ باشند. تمام فیلدهای متنی با UTF-8 کدگذاری می‌شوند. برنامه‌های نویسنده منطبق با استاندارد باید تنها نویسه‌های اسکی ۷ بیتی قابل حمل را در هدر استاندارد ustar ذخیره کرده و هر زمان که یک مقدار متنی شامل نویسه‌های غیر اسکی باشد، از ویژگی‌های گسترش‌یافته استفاده کنند.

افزون بر مدخل x که در بالا شرح داده شد، قالب تبادل pax از یک مدخل g نیز پشتیبانی می‌کند. مدخل g از نظر قالب یکسان است، اما ویژگی‌هایی را مشخص می‌نماید که به عنوان پیش‌فرض برای تمامی مدخل‌های بعدی بایگانی عمل می‌کنند. مدخل g کاربرد چندان گسترده‌ای ندارد.

به جز مدخل‌های جدید x و g, قالب تبادل pax دارای چند تفاوت جزئی دیگر نسبت به قالب قبلی ustar است. مشکل‌سازترین مورد این است که پیوندهای سخت مجاز هستند داده‌هایی به همراه داشته باشند. این ویژگی به برنامه‌های خواننده اجازه می‌دهد هر پیوند سخت به یک فایل را بدون نیاز به بازگردانی بایگانی برای یافتن مدخل قبلی بازیابی کنند. با این حال، این امر برای برنامه‌های خواننده پایدار و مقاوم پیچیدگی ایجاد می‌کند، زیرا دیگر مشخص نیست که آیا باید فیلد size را برای مدخل‌های پیوند سخت نادیده بگیرند یا خیر.

بایگانی‌های گنو تار (GNU Tar Archives)

برنامه GNU tar با یک قالب پیش از پازیکس مشابه آنچه قبلاً بیان شد آغاز شد و با بهره‌گیری از چندین سازوکار مختلف آن را گسترش داد: فیلدهای جدیدی را به فضای خالی هدر اضافه کرد (که برخی از آن‌ها بعداً توسط POSIX برای اهداف متناقض به کار رفتند)؛ به هدر اجازه داد در چندین رکورد متوالی ادامه یابد؛ و مدخل‌های جدیدی را تعریف کرد که مدخل‌های پس از خود را اصلاح می‌کنند (از نظر ساختاری شبیه به مدخل x توصیف‌شده در بالا، با این تفاوت که بر خلاف مدخل چندمنظوره x, هر مدخل ویژه در GNU تک‌منظوره است). در نتیجه، بایگانی‌های GNU tar با POSIX سازگار نیستند، هرچند برنامه‌های خواننده منعطف‌ترِ منطبق با POSIX می‌توانند اکثر بایگانی‌های GNU tar را با موفقیت استخراج کنند.

struct header_gnu_tar {
	char name[100];
	char mode[8];
	char uid[8];
	char gid[8];
	char size[12];
	char mtime[12];
	char checksum[8];
	char typeflag[1];
	char linkname[100];
	char magic[6];
	char version[2];
	char uname[32];
	char gname[32];
	char devmajor[8];
	char devminor[8];
	char atime[12];
	char ctime[12];
	char offset[12];
	char longnames[4];
	char unused[1];
	struct {
		char offset[12];
		char numbytes[12];
	} sparse[4];
	char isextended[1];
	char realsize[12];
	char pad[17];
};

typeflag

ابزار GNU tar علاوه بر انواع تعریف‌شده در POSIX، از انواع مدخل ویژه زیر استفاده می‌کند:

7

ابزار GNU tar با رکوردهای نوع "7" دقیقاً همانند رکوردهای نوع "0" برخورد می‌کند، مگر در یک سیستم‌عامل بی‌درنگ (RTOS) گمنام که در آنجا برای مشخص کردن تخصیص اولیه یک فایل پیوسته بر روی دیسک استفاده می‌شوند.

D

این نشان‌دهنده یک مدخل دایرکتوری است. برخلاف typeflag استاندارد "5" در POSIX، پس از این هدر رکوردهای داده‌ای قرار دارند که نام فایل‌های موجود در دایرکتوری را فهرست می‌کنند. پیش از هر نام، در صورتی که فایل در این بایگانی ذخیره شده باشد نویسه اسکی "Y" و در غیر این صورت نویسه "N" قرار می‌گیرد. هر نام به یک بایت تهی ختم می‌شود، و یک بایت تهی اضافی پایان فهرست نام‌ها را مشخص می‌کند. هدف از این مدخل پشتیبانی از پشتیبان‌گیری‌های افزایشی است؛ برنامه‌ای که از چنین بایگانی بازیابی انجام می‌دهد ممکن است بخواهد فایل‌هایی را از روی دیسک حذف کند که هنگام ایجاد بایگانی در دایرکتوری وجود نداشته‌اند.

توجه داشته باشید که typeflag نوع "D" مشخصاً استاندارد POSIX را نقض می‌کند، که الزام می‌دارد با typeflagهای ناشناخته مانند فایل‌های عادی رفتار شود. در این حالت، بازیابی مدخل "D" به عنوان یک فایل می‌تواند در ایجاد بعدی دایرکتوری هم‌نام اختلال ایجاد کند.

K

داده‌های این مدخل یک linkname طولانی برای مدخل عادی بعدی است.

L

داده‌های این مدخل یک نام مسیر (pathname) طولانی برای مدخل عادی بعدی است.

M

این ادامه آخرین فایل در جلد قبلی است. بایگانی‌های چندجلدی GNU تضمین می‌کنند که هر جلد با یک هدر مدخل معتبر آغاز شود. برای اطمینان از این امر، ممکن است یک فایل تقسیم شود، به طوری که بخشی از آن در انتهای یک جلد و بخش دیگر در ابتدای جلد بعدی ذخیره گردد. پرچم نوع "M" نشان می‌دهد که این مدخل ادامه یک فایل موجود است. چنین مدخل‌هایی فقط می‌توانند به عنوان مدخل اول یا دوم در یک بایگانی ظاهر شوند (دومی فقط در صورتی که مدخل اول برچسب جلد باشد). فیلد size اندازه این مدخل را مشخص می‌کند. فیلد offset در بایت‌های ۳۶۹-۳۸۰ آفستی را که این قطعه از فایل از آن آغاز می‌شود تعیین می‌کند. فیلد realsize اندازه کل فایل را مشخص می‌نماید (که باید برابر با size به علاوه offset باشد). هنگام استخراج، GNU tar بررسی می‌کند که نام فایل در هدر همان نام مورد انتظار باشد، آفست هدر در توالی صحیح قرار داشته باشد، و مجموع آفست و اندازه برابر با realsize باشد.

N

رکوردهای نوع "N" دیگر توسط GNU tar تولید نمی‌شوند. آن‌ها شامل فهرستی از فایل‌ها برای تغییر نام یا ایجاد پیوند نمادین پس از استخراج بودند؛ این کار در اصل برای پشتیبانی از نام‌های طولانی استفاده می‌شد. محتوای این رکورد شرح متنی عملیات‌های لازم است، به فرم “Rename %s to %s\n” یا “Symlink %s to %s\n ؛” در هر دو حالت، هر دو نام فایل با استفاده از نحو زبان C استاندارد K&R اسکیپ شده‌اند. به دلایل امنیتی، رکوردهای "N" امروزه هنگام خواندن بایگانی‌ها معمولاً نادیده گرفته می‌شوند.

S

این یک فایل عادی “پراکنده (sparse)” است. فایل‌های پراکنده به صورت مجموعه‌ای از قطعات ذخیره می‌شوند. هدر شامل فهرستی از جفت‌های آفست/طول قطعات است. اگر به بیش از چهار مدخل از این دست نیاز باشد، هدر در صورت لزوم با پسوندهای هدر “اضافی (extra)” (قالب قدیمی‌تری که دیگر استفاده نمی‌شود) یا پسوندهای “پراکنده (sparse)” گسترش می‌یابد.

V

فیلد name باید به عنوان نام هدر نوار/جلد تفسیر شود. این مدخل هنگام استخراج عموماً نادیده گرفته می‌شود.

magic

فیلد magic شامل پنج نویسه “ustar” است که پس از آن یک نویسه فاصله قرار دارد. توجه داشته باشید که بایگانی‌های POSIX ustar دارای یک بایت تهی پایانی هستند.

version

فیلد version شامل یک نویسه فاصله و به دنبال آن یک بایت تهی است. توجه داشته باشید که بایگانی‌های POSIX ustar از دو نسخه از رقم اسکی “0” استفاده می‌کنند.

atime, ctime

زمان آخرین دسترسی به فایل و زمان آخرین تغییر در اطلاعات فایل، ذخیره‌شده به صورت مبنای هشت همانند mtime.

longnames

ظاهراً این فیلد دیگر استفاده نمی‌شود.

Sparse offset / numbytes

هر ساختاری از این نوع، یک قطعه منفرد از یک فایل پراکنده (sparse) را مشخص می‌کند. این دو فیلد مقادیر را به صورت اعداد مبنای هشت ذخیره می‌کنند. هر یک از قطعات در بایگانی به مضربی از ۵۱۲ بایت تراز (pad) می‌شوند. هنگام استخراج، فهرست قطعات از هدر (شامل هرگونه هدر پسوند) جمع‌آوری می‌شود و سپس داده‌ها خوانده شده و در آفست‌های مناسب در فایل نوشته می‌شوند.

isextended

اگر این مقدار غیر صفر باشد، به دنبال هدر رکوردهای تکمیلی “هدر پراکنده (sparse header)” خواهند آمد. هر رکورد از این دست شامل اطلاعات حداکثر ۲۱ بلوک پراکنده اضافی است، همان‌طور که در اینجا نشان داده شده است:

struct gnu_sparse_header {
	struct {
		char offset[12];
		char numbytes[12];
	} sparse[21];
	char    isextended[1];
	char    padding[7];
};

realsize

یک نمایش باینری از اندازه کامل فایل، با بازه‌ای بسیار بزرگ‌تر از اندازه فایل در POSIX. به ویژه، در فایل‌های نوع M, مدخل فعلی تنها بخشی از فایل است. در این حالت، فیلد اندازه در POSIX اندازه این مدخل را نشان می‌دهد؛ فیلد realsize اندازه کل فایل را مشخص خواهد کرد.

بایگانی‌های pax در گنو تار (GNU tar pax archives)

ابزار GNU tar از نسخه ۱.۱۴ به بعد هنگام مشخص کردن پرچم --posix, بایگانی‌هایی با قالب تبادل pax می‌نویسد. این قالب از قالب تبادل pax از نزدیک پیروی می‌کند، و از برخی برچسب‌های SCHILY استفاده کرده و کلیدواژه‌های جدیدی را برای ذخیره اطلاعات فایل‌های پراکنده معرفی می‌نماید. سه نسخه از پشتیبانی فایل‌های پراکنده وجود داشته است که به نام‌های “0.0”, “0.1” و “1.0” شناخته می‌شوند.

GNU.sparse.numblocks, GNU.sparse.offset, GNU.sparse.numbytes, GNU.sparse.size

قالب “0.0” از یک ویژگی اولیه به نام GNU.sparse.numblocks برای مشخص کردن تعداد بلوک‌های موجود در فایل، یک جفت از GNU.sparse.offset و GNU.sparse.numbytes برای مشخص کردن آفست و اندازه هر بلوک، و یک ویژگی منفرد GNU.sparse.size برای نشان دادن اندازه کامل فایل استفاده می‌کرد. این مقدار با اندازه موجود در هدر tar یکسان نیست زیرا مقدار اخیر اندازه حفره‌ها را شامل نمی‌شود. این قالب مستلزم حفظ ترتیب ویژگی‌ها بود و به پذیرش تکرار نام ویژگی‌های یکسان توسط برنامه‌های خواننده متکی بود، که این امر رسماً توسط استانداردها مجاز شناخته نشده است.

GNU.sparse.map

قالب “0.1” از یک ویژگی منفرد استفاده می‌کرد که فهرستی از اعداد ده‌دهی جداشده با کاما را ذخیره می‌نمود. هر جفت عدد به ترتیب نشان‌دهنده آفست و اندازه یک بلوک از داده‌ها بود. اگر بایگانی توسط برنامه‌ای استخراج شود که این پسوند را نمی‌شناسد این روش به خوبی کار نمی‌کند، زیرا بسیاری از پیاده‌سازی‌های pax ویژگی‌های ناشناخته را نادیده گرفته و حذف می‌کنند.

GNU.sparse.major, GNU.sparse.minor, GNU.sparse.name, GNU.sparse.realsize

قالب “1.0” نقشه بلوک‌های پراکنده را در یک یا چند بلوک ۵۱۲ بایتی ذخیره می‌کند که قبل از داده‌های فایل در بدنه مدخل قرار می‌گیرند. ویژگی‌های pax وجود این نقشه را (از طریق فیلدهای GNU.sparse.major و GNU.sparse.minor) و اندازه کامل فایل مشخص می‌نمایند. ویژگی GNU.sparse.name نام واقعی فایل را نگهداری می‌کند. برای جلوگیری از سردرگمی، نام ذخیره‌شده در هدر عادی tar یک نام دستکاری‌شده است تا خطاهای استخراج برای کاربران آشکار باشد.

تار در سولاریس (Solaris Tar)

ابزار Solaris tar (از نگارش SunOS 5.7 به بعد) از یک قالب “گسترش‌یافته” پشتیبانی می‌کند که اساساً شبیه به قالب تبادل pax است، با تفاوت‌های زیر:

• ویژگی‌های گسترش‌یافته در مدخلی ذخیره می‌شوند که نوع آن X است، نه x که در قالب تبادل pax به کار می‌رود. به نظر می‌رسد قالب تفصیلی این مدخل مشابه قالب ارائه‌شده در بالا برای مدخل x باشد.
• یک هدر تکمیلی A برای ذخیره یک فهرست کنترل دسترسی (ACL) برای مدخل عادی بعدی استفاده می‌شود. بدنه این مدخل شامل یک عدد مبنای هشت هفت‌رقمی است که به دنبال آن یک بایت صفر و سپس توضیحات متنی ACL قرار می‌گیرد. مقدار مبنای هشت، تعداد مدخل‌های ACL به علاوه یک مقدار ثابت است که نوع ACL را مشخص می‌کند: 01000000 برای ACLهای POSIX.1e و 03000000 برای ACLهای NFSv4.

تار در ای‌آی‌اکس (AIX Tar)

ابزار AIX Tar از یک هدر با قالب ustar و نوع A برای ذخیره اطلاعات کدگذاری‌شده ACL استفاده می‌کند. برخلاف قالب سولاریس، ابزار AIX tar این هدر را پس از بدنه فایل عادی مربوطه می‌نویسد. نام مسیر در این هدر یا NFS4 یا AIXC است تا نوع ACL ذخیره‌شده را نشان دهد. خودِ ACL در قالب باینری وابسته به پلتفرم ذخیره می‌شود.

تار در مک او اس ده (Mac OS X Tar)

ابزار tar ارائه‌شده در سیستم‌عامل Mac OS X شرکت اپل، بیشتر فایل‌های عادی را به صورت دو فایل جداگانه در بایگانی tar ذخیره می‌کند. این دو فایل دارای نام یکسانی هستند به جز اینکه در ابتدای آخرین مؤلفه مسیر فایل اول، عبارت “._” افزوده می‌شود. این فایل ویژه، یک حباب باینری کدگذاری‌شده در قالب AppleDouble را با فراداده‌های تکمیلی درباره فایل دوم شامل ACL، ویژگی‌های گسترش‌یافته و منابع ذخیره می‌کند. برای بازسازی فایل اصلی بر روی دیسک، هر فایل به صورت جداگانه قابل استخراج است و می‌توان از تابع copyfile() در Mac OS X برای باز کردن بسته فایل فراداده مجزا و اعمال آن بر روی فایل عادی استفاده کرد. برعکس، همین تابع گزینه‌ای به نام “pack” فراهم می‌سازد تا فراداده‌های گسترش‌یافته یک فایل درون یک فایل مجزا کدگذاری شود که سپس محتویات آن می‌تواند در یک بایگانی tar قرار گیرد.

توجه داشته باشید که ویژگی‌های گسترش‌یافته اپل با نام‌های فایل طولانی تداخل نامناسبی دارند. از آنجا که هر فایل با نام کامل ذخیره می‌شود، باید یک مجموعه مجزا از پسوندها در بایگانی برای هر کدام گنجانده شود که این امر سربار مورد نیاز برای فایل‌های با نام‌های طولانی را دو برابر می‌کند.

خلاصه کدهای نوع tar (Summary of tar type codes)

فهرست زیر خلاصه‌ای فشرده از کدهای نوع به‌کاررفته در رکوردهای هدر tar است که توسط پیاده‌سازی‌های گوناگون tar تولید می‌شوند. جزئیات بیشتر درباره پیاده‌سازی‌های خاص را می‌توان در بالا یافت:

NUL

برنامه‌های اولیه tar یک بایت صفر را برای فایل‌های عادی ذخیره می‌کردند.

0

کد نوع استاندارد POSIX برای یک فایل عادی.

1

کد نوع استاندارد POSIX برای شرح یک پیوند سخت.

2

کد نوع استاندارد POSIX برای شرح یک پیوند نمادین.

3

کد نوع استاندارد POSIX برای یک گره دستگاه کاراکتری.

4

کد نوع استاندارد POSIX برای یک گره دستگاه بلوکی.

5

کد نوع استاندارد POSIX برای یک دایرکتوری.

6

کد نوع استاندارد POSIX برای یک FIFO (لوله نام‌گذاری‌شده).

7

رزرو شده توسط POSIX.

7

در GNU tar برای فایل‌های از پیش تخصیص‌یافته در برخی سیستم‌ها استفاده می‌شود.

A

شرح ACL در Solaris tar که پیش از هدر فایل عادی ذخیره می‌شود.

A

شرح ACL در AIX tar که پس از بدنه فایل ذخیره می‌شود.

D

تخلیه دایرکتوری در GNU tar.

K

نام پیوند (linkname) طولانی در GNU tar برای هدر بعدی.

L

نام مسیر (pathname) طولانی در GNU tar برای هدر بعدی.

M

نشانگر چندجلدی در GNU tar، که مشخص می‌کند این فایل ادامه فایلی از جلد قبلی است.

N

پشتیبانی از نام فایل طولانی در GNU tar. منسوخ شده است.

S

فایل عادی پراکنده (sparse) در GNU tar.

V

نام هدر نوار/جلد در GNU tar.

X

هدر پسوند عمومی در Solaris tar.

g

پسوندهای سراسری در قالب تبادل pax استاندارد POSIX.

x

پسوندهای اختصاصی هر فایل در قالب تبادل pax استاندارد POSIX.