.\" Copyright (c) 2003-2009 Tim Kientzle
.\" Copyright (c) 2016 Martin Matuska
.\" All rights reserved.
.\"
.\" Redistribution and use in source and binary forms, with or without
.\" modification, are permitted provided that the following conditions
.\" are met:
.\" 1. Redistributions of source code must retain the above copyright
.\"    notice, this list of conditions and the following disclaimer.
.\" 2. Redistributions in binary form must reproduce the above copyright
.\"    notice, this list of conditions and the following disclaimer in the
.\"    documentation and/or other materials provided with the distribution.
.\"
.\" THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND
.\" ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
.\" IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
.\" ARE DISCLAIMED.  IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE
.\" FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
.\" DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
.\" OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
.\" HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
.\" LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
.\" OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
.\" SUCH DAMAGE.
.\"
.Dd December 27, 2016
.Dt TAR 5
.Os
.Sh "نام (NAME)"
.Nm tar
.Nd قالب پرونده‌های بایگانی نوار (Tape Archive)
.Sh "توضیحات (DESCRIPTION)"
قالب بایگانی
.Nm
هر تعداد فایل، دایرکتوری و سایر اشیای سیستم پرونده (پیوندهای نمادین، گره‌های دستگاه و غیره) را در یک جریان پیوسته از بایت‌ها گردآوری می‌کند.
این قالب در ابتدا برای استفاده در گرداننده‌های نوار مغناطیسی با اندازه بلوک ثابت طراحی شده بود، اما امروزه به عنوان یک سازوکار عمومی بسته‌بندی کاربرد گسترده‌ای دارد.
.Ss "قالب کلی (General Format)"
یک بایگانی
.Nm
شامل مجموعه‌ای از رکوردهای ۵۱۲ بایتی است.
هر شیء در سیستم پرونده نیازمند یک رکورد هدر است که فراداده‌های اساسی (نام مسیر، مالک، مجوزها و غیره) را ذخیره می‌کند و به دنبال آن صفر یا چند رکورد حاوی داده‌های فایل قرار می‌گیرد.
پایان بایگانی با دو رکورد مشخص می‌شود که تماماً شامل بایت‌های صفر هستند.
.Pp
به منظور سازگاری با گرداننده‌های نواری که از اندازه‌های بلوک ثابت استفاده می‌کنند، برنامه‌های خواننده یا نویسنده فایل‌های tar همیشه در هر عملیات ورودی/خروجی (I/O) تعداد ثابتی رکورد را می‌خوانند یا می‌نویسند.
این
.Dq بلوک‌ها
همواره مضربی از اندازه رکورد هستند.
حداکثر اندازه بلوک پشتیبانی‌شده در پیاده‌سازی‌های اولیه ۱۰۲۴۰ بایت یا ۲۰ رکورد بود.
این مقدار همچنان در بیشتر پیاده‌سازی‌ها حالت پیش‌فرض است، اگرچه امروزه در درایوهای نوار پرسرعت مدرن معمولاً اندازه‌های بلوک ۱ مبی‌بایت (۲۰۴۸ رکورد) یا بزرگ‌تر به کار می‌روند.
(توجه: اصطلاحات
.Dq بلوک
و
.Dq رکورد
در اینجا کاملاً استاندارد نیستند؛ این سند از قرارداد وضع‌شده توسط John Gilmore در مستندسازی
.Nm pdtar
پیروی می‌کند.)
.Ss "قالب بایگانی سبک قدیم (Old-Style Archive Format)"
قالب سنتی بایگانی tar بارها گسترش یافته است تا اطلاعات تکمیلی مورد نیاز پیاده‌سازان مختلف را در بر گیرد.
این بخش گونه‌ای را شرح می‌دهد که توسط دستور tar در
.At v7
پیاده‌سازی شده بود و به نظر می‌رسد نخستین نسخه پرکاربرد برنامه tar باشد.
.Pp
رکورد هدر برای یک بایگانی
.Nm
به سبک قدیم از ساختار زیر تشکیل شده است:
.nf
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];
};
.fi
تمامی بایت‌های استفاده‌نشده در رکورد هدر با بایت‌های تهی (null) پر می‌شوند.
.Bl -tag -width indent
.It Va name
نام مسیر، ذخیره‌شده به عنوان یک رشته منتهی به تهی (null-terminated).
پیاده‌سازی‌های اولیه tar تنها فایل‌های عادی (شامل پیوندهای سخت به آن فایل‌ها) را ذخیره می‌کردند.
یک قرارداد رایج اولیه، استفاده از نویسه اسلش پایانی "/" برای مشخص کردن نام دایرکتوری بود که امکان بایگانی و بازیابی مجوزها و اطلاعات مالک دایرکتوری را فراهم می‌کرد.
.It Va mode
حالت (mode) فایل، ذخیره‌شده به عنوان عدد در مبنای هشت (اکتال) در قالب اسکی.
.It Va uid , Va gid
شناسه کاربر و شناسه گروه مالک فایل، به صورت اعداد مبنای هشت در قالب اسکی.
.It Va size
اندازه فایل، به صورت عدد مبنای هشت در قالب اسکی.
تنها برای فایل‌های عادی، این فیلد نمایانگر مقدار داده‌ای است که پس از هدر قرار دارد.
به ویژه، این فیلد در پیاده‌سازی‌های اولیه tar هنگام استخراج پیوندهای سخت نادیده گرفته می‌شد.
برنامه‌های نویسنده مدرن باید همیشه برای مدخل‌های پیوند سخت اندازه صفر را ذخیره کنند.
.It Va mtime
زمان آخرین تغییر فایل، به صورت عدد مبنای هشت در قالب اسکی.
این فیلد تعداد ثانیه‌های سپری‌شده از مبدأ زمانی یونیکس (Epoch)، یعنی ساعت 00:00:00 UTC در ۱ ژانویه ۱۹۷۰ را مشخص می‌کند.
توجه داشته باشید که باید از مقادیر منفی در اینجا اجتناب شود، زیرا رفتار هماهنگی در پردازش آن‌ها وجود ندارد.
.It Va checksum
مجموع مقابله‌ای (checksum) هدر، ذخیره‌شده به عنوان عدد مبنای هشت در قالب اسکی.
برای محاسبه چک‌سام، ابتدا فیلد چک‌سام را تماماً با نویسه‌های فاصله پر کنید، سپس تمام بایت‌های هدر را با استفاده از محاسبات حسابی بدون علامت (unsigned) جمع بزنید.
این فیلد باید به صورت شش رقم مبنای هشت و به دنبال آن یک بایت تهی و یک نویسه فاصله ذخیره شود.
توجه داشته باشید که بسیاری از پیاده‌سازی‌های اولیه tar از محاسبات علامت‌دار برای فیلد چک‌سام استفاده می‌کردند که این امر می‌تواند هنگام انتقال بایگانی‌ها میان سیستم‌ها مشکلات سازگاری ایجاد کند.
برنامه‌های خواننده قدرتمند و مدرن، چک‌سام را به هر دو روش محاسبه می‌کنند و در صورت تطابق با هر یک، هدر را معتبر می‌شناسند.
.It Va linkflag , Va linkname
به منظور حفظ پیوندهای سخت و صرفه‌جویی در فضای نوار، فایلی که دارای پیوندهای متعدد است فقط در نخستین مواجهه در بایگانی نوشته می‌شود.
در دفعات بعدی مواجهه، فیلد
.Va linkflag
روی نویسه اسکی
.Sq 1
تنظیم شده و فیلد
.Va linkname
نخستین نامی را که فایل تحت آن ظاهر شده نگهداری می‌کند.
(توجه داشته باشید که فایل‌های عادی دارای مقدار تهی در فیلد
.Va linkflag
هستند.)
.El
.Pp
پیاده‌سازی‌های اولیه tar در نحوه خاتمه دادن به این فیلدها تفاوت‌هایی داشتند.
دستور tar در
.At v7
از قراردادهای زیر استفاده می‌کرد (این موضوع در صفحات راهنمای اولیه BSD نیز مستند شده است):
نام مسیر باید به بایت تهی ختم شود؛
فیلدهای mode، uid و gid باید به یک فاصله و یک بایت تهی ختم شوند؛
فیلدهای size و mtime باید به یک فاصله ختم شوند؛
چک‌سام به یک بایت تهی و یک فاصله ختم می‌شود.
پیاده‌سازی‌های اولیه فیلدهای عددی را با فاصله‌های پیشرو (leading spaces) پر می‌کردند.
به نظر می‌رسد این یک رویه معمول تا زمان انتشار استاندارد
.St -p1003.1-88
بوده است.
برای حفظ حداکثر سازگاری و قابلیت حمل، پیاده‌سازی‌های مدرن باید فیلدهای عددی را با صفرهای پیشرو پر کنند.
.Ss "بایگانی‌های پیش از پازیکس (Pre-POSIX Archives)"
پیش‌نویس اولیه‌ای از استاندارد
.St -p1003.1-88
به عنوان پایه‌ای برای برنامه
.Nm pdtar
نوشته John Gilmore و بسیاری از پیاده‌سازی‌های سیستمی در اواخر دهه ۱۹۸۰ و اوایل دهه ۱۹۹۰ عمل کرد.
این بایگانی‌ها به طور کلی از قالب POSIX ustar شرح‌داده‌شده در زیر با تفاوت‌های زیر پیروی می‌کنند:
.Bl -bullet -compact -width indent
.It
مقدار جادویی (magic) شامل پنج نویسه
.Dq ustar
است که پس از آن یک نویسه فاصله قرار دارد.
فیلد نسخه (version) شامل یک نویسه فاصله و به دنبال آن یک بایت تهی است.
.It
فیلدهای عددی معمولاً با فاصله‌های پیشرو پر می‌شوند
(نه با صفرهای پیشرو طبق توصیه استاندارد نهایی).
.It
فیلد پیشوند (prefix) اغلب استفاده نمی‌شود و طول نام مسیرها را به ۱۰۰ نویسه همانند بایگانی‌های سبک قدیم محدود می‌کند.
.El
.Ss "بایگانی‌های POSIX ustar (POSIX ustar Archives)"
استاندارد
.St -p1003.1-88
یک قالب فایل استاندارد tar را تعریف کرد تا توسط پیاده‌سازی‌های منطبق با
.Xr tar 1
خوانده و نوشته شود.
این قالب اغلب پس از مقدار جادویی به‌کاررفته در هدر، قالب
.Dq ustar
نامیده می‌شود.
(این نام کوته‌نوشتی از
.Dq Unix Standard TAR
است.)
این استاندارد، قالب تاریخی را با فیلدهای جدیدی گسترش می‌دهد:
.nf
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];
};
.fi
.Bl -tag -width indent
.It Va typeflag
نوع مدخل.
استاندارد POSIX فیلد قبلی
.Va linkflag
را با چندین مقدار نوع جدید گسترش داد:
.Bl -tag -width indent -compact
.It Dq 0
فایل عادی.
جهت سازگاری، با NUL باید به عنوان مترادف رفتار شود.
.It Dq 1
پیوند سخت.
.It Dq 2
پیوند نمادین.
.It Dq 3
گره دستگاه کاراکتری.
.It Dq 4
گره دستگاه بلوکی.
.It Dq 5
دایرکتوری.
.It Dq 6
گره FIFO (لوله نام‌گذاری‌شده).
.It Dq 7
رزرو شده.
.It Other
یک پیاده‌سازی منطبق با POSIX باید با هر مقدار ناشناخته typeflag مانند یک فایل عادی رفتار کند.
به ویژه، برنامه‌های نویسنده باید اطمینان حاصل کنند که تمام مدخل‌ها نام فایل معتبری دارند تا بتوانند توسط برنامه‌های خواننده‌ای که از پسوند مربوطه پشتیبانی نمی‌کنند نیز بازیابی شوند.
حروف بزرگ "A" تا "Z" برای پسوندهای سفارشی رزرو شده‌اند.
توجه داشته باشید که سوکت‌ها (sockets) و مدخل‌های whiteout قابل بایگانی نیستند.
.El
شایان ذکر است که فیلد
.Va size
به طور ویژه بسته به نوع مدخل دارای معانی متفاوتی است.
برای فایل‌های عادی، مسلماً این فیلد مقدار داده‌ای را نشان می‌دهد که پس از هدر می‌آید.
برای دایرکتوری‌ها، ممکن است برای نشان دادن اندازه کل تمام فایل‌های موجود در دایرکتوری استفاده شود تا توسط سیستم‌عامل‌هایی که فضای دایرکتوری را از پیش تخصیص می‌دهند به کار رود.
برای تمامی انواع دیگر، باید توسط برنامه‌های نویسنده روی صفر تنظیم شده و توسط برنامه‌های خواننده نادیده گرفته شود.
.It Va magic
شامل مقدار جادویی
.Dq ustar
به همراه یک بایت NUL برای نشان دادن این است که این یک بایگانی استاندارد POSIX است.
انطباق کامل مستلزم مقداردهی صحیح فیلدهای uname و gname است.
.It Va version
نسخه.
این مقدار برای بایگانی‌های استاندارد POSIX باید
.Dq 00
(دو نسخه از رقم صفر اسکی) باشد.
.It Va uname , Va gname
نام‌های کاربر و گروه به عنوان رشته‌های اسکی منتهی به تهی.
این نام‌ها در صورت تنظیم بودن و وجود نام‌های متناظر در سیستم، باید نسبت به مقادیر uid/gid در اولویت قرار گیرند.
.It Va devmajor , Va devminor
شماره‌های اصلی (major) و فرعی (minor) برای مدخل‌های دستگاه کاراکتری یا دستگاه بلوکی.
.It Va name , Va prefix
اگر نام مسیر برای جا شدن در ۱۰۰ بایت ارائه‌شده در قالب استاندارد بیش از حد طولانی باشد، می‌توان آن را در هر نویسه
.Pa /
شکست، به گونه‌ای که بخش نخست درون فیلد prefix قرار گیرد.
اگر فیلد prefix خالی نباشد، برنامه خواننده مقدار prefix و یک نویسه
.Pa /
را به ابتدای فیلد نام عادی اضافه می‌کند تا نام مسیر کامل به دست آید.
استاندارد نیازی به وجود نویسه پایانی
.Pa /
در نام دایرکتوری‌ها ندارد، هرچند بیشتر پیاده‌سازی‌ها همچنان به دلایل سازگاری آن را درج می‌کنند.
.El
.Pp
توجه داشته باشید که تمام بایت‌های استفاده‌نشده باید روی
.Dv NUL
تنظیم شوند.
.Pp
پایان فیلدها در POSIX اندکی متفاوت از پیاده‌سازی‌های پیشین مشخص شده است.
فیلدهای
.Va magic ,
.Va uname
و
.Va gname
باید دارای یک بایت پایانی
.Dv NUL
باشند.
فیلدهای
.Va pathname ,
.Va linkname
و
.Va prefix
باید دارای یک بایت پایانی
.Dv NUL
باشند مگر اینکه کل فیلد را پر کرده باشند.
(به ویژه، ذخیره یک نام مسیر ۲۵۶ نویسه‌ای امکان‌پذیر است اگر نویسه ۱۵۶ام آن تصادفاً یک
.Pa /
باشد.)
استاندارد POSIX نیازمند آن است که فیلدهای عددی با صفر در ابتدا پر شوند و پایان آن‌ها با نویسه‌های فاصله یا
.Dv NUL
مشخص گردد.
.Pp
در حال حاضر بیشتر پیاده‌سازی‌های tar با قالب ustar مطابقت دارند و گاهی آن را با افزودن فیلدهای جدید به فضای خالی انتهای رکورد هدر گسترش می‌دهند.
.Ss "پسوندهای عددی (Numeric Extensions)"
تلاش‌های متعددی برای گسترش بازه اندازه‌ها یا زمان‌های پشتیبانی‌شده از طریق اصلاح شیوه ذخیره اعداد در هدر صورت گرفته است.
.Pp
یک راهکار بدیهی برای افزایش اندازه فایل‌ها، حذف نویسه‌های پایان‌دهنده از فیلدهای عددی گوناگون است.
به عنوان نمونه، استاندارد تنها اجازه می‌دهد فیلد size شامل ۱۱ رقم در مبنای هشت باشد و بایت دوازدهم را برای نویسه پایانی NUL رزرو می‌کند.
اجازه دادن به ۱۲ رقم در مبنای هشت، امکان ذخیره فایل‌هایی تا اندازه ۶۴ گیگابایت را فراهم می‌سازد.
.Pp
پسوند دیگر که توسط GNU tar، star و سایر پیاده‌سازی‌های جدیدتر
.Nm
به کار گرفته شده است، استفاده از اعداد دودویی (باینری) در فیلدهای عددی استاندارد را ممکن می‌سازد.
این حالت با تنظیم بیت بالای بایت اول مشخص می‌شود.
باقی‌مانده فیلد به عنوان یک مقدار علامت‌دار متمم دو (twos-complement) پردازش می‌گردد.
این شیوه مقادیر ۹۵ بیتی را برای فیلدهای طول و زمان، و مقادیر ۶۳ بیتی را برای شماره‌های uid، gid و دستگاه فراهم می‌سازد.
به ویژه، این روش راهکاری هماهنگ برای مدیریت مقادیر زمانی منفی ارائه می‌دهد.
ابزار GNU tar از این پسوند برای فیلدهای length، mtime، ctime و atime پشتیبانی می‌کند.
برنامه star نوشته Joerg Schilling و کتابخانه libarchive از این پسوند برای تمامی فیلدهای عددی پشتیبانی می‌نمایند.
توجه داشته باشید که این پسوند تا حد زیادی با رکورد ویژگی‌های گسترش‌یافته ارائه‌شده در قالب تبادل pax منسوخ شده است.
.Pp
یکی دیگر از پسوندهای اولیه GNU، اجازه استفاده از مقادیر base-64 را به جای مبنای هشت می‌داد.
این پسوند عمر کوتاهی داشت و امروزه دیگر توسط هیچ پیاده‌سازی پشتیبانی نمی‌شود.
.Ss "قالب تبادل پکس (Pax Interchange Format)"
ویژگی‌های بسیاری وجود دارند که نمی‌توان آن‌ها را به صورت قابل حمل در یک بایگانی POSIX ustar ذخیره کرد.
استاندارد
.St -p1003.1-2001
یک
.Dq قالب تبادل pax
را تعریف کرد که از دو نوع مدخل جدید برای نگهداری فراداده‌های متنی که بر مدخل‌های بعدی اعمال می‌شوند، استفاده می‌کند.
توجه داشته باشید که یک بایگانی با قالب تبادل pax از هر نظر یک بایگانی ustar محسوب می‌شود.
داده‌های جدید در مدخل‌های بایگانی سازگار با ustar ذخیره می‌شوند که از typeflag با مقدار
.Dq x
یا
.Dq g
استفاده می‌نمایند.
به ویژه، پیاده‌سازی‌های قدیمی‌تر که به طور کامل از این پسوندها پشتیبانی نمی‌کنند، فراداده‌ها را درون فایل‌های عادی استخراج می‌کنند که در آنجا می‌توان در صورت نیاز آن‌ها را بررسی کرد.
.Pp
یک مدخل در بایگانی با قالب تبادل pax از یک یا دو مدخل استاندارد ustar تشکیل می‌شود که هر کدام هدر و داده‌های خود را دارند.
نخستین مدخل اختیاری، ویژگی‌های گسترش‌یافته را برای مدخل بعدی ذخیره می‌کند.
این مدخل اختیاری دارای typeflag با مقدار "x" و یک فیلد size است که اندازه کل ویژگی‌های گسترش‌یافته را نشان می‌دهد.
خودِ ویژگی‌های گسترش‌یافته به صورت مجموعه‌ای از خطوط متنی با کدبندی قابل حمل UTF-8 ذخیره می‌شوند.
هر خط شامل یک عدد در مبنای ده (ده‌دهی)، یک فاصله، یک رشته کلید (key)، یک علامت مساوی، یک رشته مقدار (value) و یک خط جدید است.
عدد ده‌دهی طول کل خط را شامل فیلد طول اولیه و خط جدید پایانی مشخص می‌کند.
نمونه‌ای از چنین فیلدی به صورت زیر است:
.Dl 25 ctime=1084839148.1212\en
کلیدهایی که تماماً با حروف کوچک نوشته شده‌اند، کلیدهای استاندارد هستند.
تولیدکنندگان نرم‌افزار می‌توانند کلیدهای اختصاصی خود را با پیشوند نام تولیدکننده با حروف بزرگ و یک نقطه اضافه کنند.
توجه داشته باشید که برخلاف هدر تاریخی، مقادیر عددی با استفاده از مبنای ده ذخیره می‌شوند، نه مبنای هشت.
شرح برخی از کلیدهای متداول در ادامه آمده است:
.Bl -tag -width indent
.It Cm atime , Cm ctime , Cm mtime
زمان‌های دسترسی به فایل، تغییر اینود (inode) و آخرین تغییر در محتوای فایل.
این فیلدها می‌توانند منفی باشند یا شامل ممیز اعشاری و مقادیر کسری باشند.
.It Cm hdrcharset
مجموعه نویسه‌های به‌کاررفته در مقادیر پسوند pax.
به طور پیش‌فرض، فرض می‌شود که تمام مقادیر متنی در ویژگی‌های گسترش‌یافته pax در قالب UTF-8 هستند، از جمله نام مسیرها، نام‌های کاربری و نام‌های گروه.
در برخی موارد، ترجمه قراردادهای محلی به UTF-8 امکان‌پذیر نیست.
اگر این کلید وجود داشته باشد و مقدار آن رشته اسکی شش‌نویسه‌ای
.Dq BINARY
باشد، آنگاه تمام مقادیر متنی در یک کدبندی چندبایتی وابسته به پلتفرم فرض می‌شوند.
توجه داشته باشید که تنها دو مقدار معتبر برای این کلید وجود دارد:
.Dq BINARY
یا
.Dq ISO-IR\ 10646\ 2000\ UTF-8 .
هیچ مقدار دیگری توسط استاندارد مجاز دانسته نشده است، و از مقدار دوم عموماً نباید استفاده شود زیرا در صورت عدم تعیین این کلید، همان حالت پیش‌فرض است.
به ویژه، این پرچم نباید به عنوان یک سازوکار عمومی برای مجاز ساختن ذخیره نام فایل‌ها در کدبندی‌های دلخواه به کار رود.
.It Cm uname , Cm uid , Cm gname , Cm gid
نام کاربر، نام گروه، و مقادیر عددی UID و GID.
نام کاربری و نام گروه ذخیره‌شده در اینجا با UTF-8 کدگذاری می‌شوند و بنابراین می‌توانند شامل نویسه‌های غیر اسکی باشند.
فیلدهای UID و GID می‌توانند طولی دلخواه داشته باشند.
.It Cm linkpath
مسیر کامل فایلی که به آن پیوند داده شده است.
توجه داشته باشید که این مقدار با UTF-8 کدگذاری می‌شود و می‌تواند شامل نویسه‌های غیر اسکی باشد.
.It Cm path
نام مسیر کامل مدخل.
توجه داشته باشید که این مقدار با UTF-8 کدگذاری می‌شود و می‌تواند شامل نویسه‌های غیر اسکی باشد.
.It Cm realtime.* , Cm security.*
این کلیدها رزرو شده‌اند و ممکن است برای استانداردسازی‌های آینده به کار روند.
.It Cm size
اندازه فایل.
توجه داشته باشید که هیچ محدودیتی در طول برای این فیلد وجود ندارد، که به بایگانی‌های منطبق با استاندارد اجازه می‌دهد فایل‌هایی بسیار بزرگ‌تر از محدودیت سنتی ۸ گیگابایت را ذخیره کنند.
.It Cm SCHILY.*
ویژگی‌های اختصاصی توسعه‌دهنده که توسط پیاده‌سازی
.Nm star
نوشته Joerg Schilling به کار می‌روند.
.It Cm SCHILY.acl.access , Cm SCHILY.acl.default , Cm SCHILY.acl.ace
لیست‌های دسترسی، پیش‌فرض و ACLهای NFSv4 را به عنوان رشته‌های متنی در قالبی ذخیره می‌کند که پسوندی از قالب مشخص‌شده در پیش‌نویس ۱۷ استاندارد POSIX.1e است.
به ویژه، هر مشخصه دسترسی کاربر یا گروه می‌تواند شامل یک فیلد اضافی جداشده با دونقطه به همراه UID یا GID عددی باشد.
این امر امکان بازیابی ACLها را در سیستم‌هایی که ممکن است اطلاعات کامل کاربر یا گروه را در دسترس نداشته باشند (مانند زمان‌هایی که سرویس‌های NIS/YP یا LDAP موقتاً قطع هستند) فراهم می‌سازد.
.It Cm SCHILY.devminor , Cm SCHILY.devmajor
شماره‌های کامل فرعی و اصلی برای گره‌های دستگاه.
.It Cm SCHILY.fflags
پرچم‌های فایل (File flags).
.It Cm SCHILY.realsize
اندازه کامل فایل بر روی دیسک.
.It Cm SCHILY.dev , Cm SCHILY.ino , Cm SCHILY.nlinks
شماره دستگاه، شماره اینود و تعداد پیوندها برای مدخل.
به ویژه، توجه داشته باشید که یک بایگانی با قالب تبادل pax که از پسوندهای
.Cm SCHILY.*
نوشته Joerg Schilling استفاده می‌کند، می‌تواند تمامی داده‌های موجود در
.Va struct stat
را ذخیره نماید.
.It Cm LIBARCHIVE.*
ویژگی‌های اختصاصی توسعه‌دهنده که توسط کتابخانه
.Nm libarchive
و برنامه‌های استفاده‌کننده از آن به کار می‌روند.
.It Cm LIBARCHIVE.creationtime
زمان ایجاد فایل.
(این مورد نباید با ویژگی POSIX
.Dq ctime
اشتباه گرفته شود که به زمان آخرین تغییر در فراداده‌های فایل اشاره دارد.)
.It Cm LIBARCHIVE.xattr . Ns Ar namespace . Ns Ar key
کتابخانه libarchive ویژگی‌های گسترش‌یافته به سبک POSIX.1e را با استفاده از کلیدهایی به این فرم ذخیره می‌کند.
مقدار
.Ar key
به صورت URL کدگذاری می‌شود (URL-encoded):
تمام نویسه‌های غیر اسکی و دو نویسه ویژه
.Dq =
و
.Dq %
به صورت
.Dq %
و به دنبال آن دو رقم هگزادسیمال با حروف بزرگ کدگذاری می‌شوند.
مقدار این کلید، مقدار ویژگی گسترش‌یافته کدگذاری‌شده در قالب base 64 است.
.It Cm VENDOR.*
پسوندهای اختصاصی سایر تولیدکنندگان نرم‌افزار.
.El
.Pp
هر مقداری که در یک ویژگی گسترش‌یافته ذخیره شده باشد، بر مقادیر متناظر در هدر استاندارد tar اولویت داشته و جایگزین آن می‌شود.
توجه داشته باشید که برنامه‌های خواننده منطبق با استاندارد باید در صورت جایگزینی، فیلدهای عادی را نادیده بگیرند.
این امر مهم است، زیرا برنامه‌های بایگانی‌کننده موجود در این شرایط مقادیر نامنطبق با استاندارد را در فیلدهای هدر استاندارد ذخیره می‌کنند.
هیچ محدودیتی در طول برای هیچ‌یک از این فیلدها وجود ندارد.
به ویژه، فیلدهای عددی می‌توانند به دلخواه بزرگ باشند.
تمام فیلدهای متنی با UTF-8 کدگذاری می‌شوند.
برنامه‌های نویسنده منطبق با استاندارد باید تنها نویسه‌های اسکی ۷ بیتی قابل حمل را در هدر استاندارد ustar ذخیره کرده و هر زمان که یک مقدار متنی شامل نویسه‌های غیر اسکی باشد، از ویژگی‌های گسترش‌یافته استفاده کنند.
.Pp
افزون بر مدخل
.Cm x
که در بالا شرح داده شد، قالب تبادل pax از یک مدخل
.Cm g
نیز پشتیبانی می‌کند.
مدخل
.Cm g
از نظر قالب یکسان است، اما ویژگی‌هایی را مشخص می‌نماید که به عنوان پیش‌فرض برای تمامی مدخل‌های بعدی بایگانی عمل می‌کنند.
مدخل
.Cm g
کاربرد چندان گسترده‌ای ندارد.
.Pp
به جز مدخل‌های جدید
.Cm x
و
.Cm g ,
قالب تبادل pax دارای چند تفاوت جزئی دیگر نسبت به قالب قبلی ustar است.
مشکل‌سازترین مورد این است که پیوندهای سخت مجاز هستند داده‌هایی به همراه داشته باشند.
این ویژگی به برنامه‌های خواننده اجازه می‌دهد هر پیوند سخت به یک فایل را بدون نیاز به بازگردانی بایگانی برای یافتن مدخل قبلی بازیابی کنند.
با این حال، این امر برای برنامه‌های خواننده پایدار و مقاوم پیچیدگی ایجاد می‌کند، زیرا دیگر مشخص نیست که آیا باید فیلد size را برای مدخل‌های پیوند سخت نادیده بگیرند یا خیر.
.Ss "بایگانی‌های گنو تار (GNU Tar Archives)"
برنامه GNU tar با یک قالب پیش از پازیکس مشابه آنچه قبلاً بیان شد آغاز شد و با بهره‌گیری از چندین سازوکار مختلف آن را گسترش داد:
فیلدهای جدیدی را به فضای خالی هدر اضافه کرد (که برخی از آن‌ها بعداً توسط POSIX برای اهداف متناقض به کار رفتند)؛
به هدر اجازه داد در چندین رکورد متوالی ادامه یابد؛
و مدخل‌های جدیدی را تعریف کرد که مدخل‌های پس از خود را اصلاح می‌کنند
(از نظر ساختاری شبیه به مدخل
.Cm x
توصیف‌شده در بالا، با این تفاوت که بر خلاف مدخل چندمنظوره
.Cm x ,
هر مدخل ویژه در GNU تک‌منظوره است).
در نتیجه، بایگانی‌های GNU tar با POSIX سازگار نیستند، هرچند برنامه‌های خواننده منعطف‌ترِ منطبق با POSIX می‌توانند اکثر بایگانی‌های GNU tar را با موفقیت استخراج کنند.
.nf
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];
};
.fi
.Bl -tag -width indent
.It Va typeflag
ابزار GNU tar علاوه بر انواع تعریف‌شده در POSIX، از انواع مدخل ویژه زیر استفاده می‌کند:
.Bl -tag -width indent
.It "7"
ابزار GNU tar با رکوردهای نوع "7" دقیقاً همانند رکوردهای نوع "0" برخورد می‌کند، مگر در یک سیستم‌عامل بی‌درنگ (RTOS) گمنام که در آنجا برای مشخص کردن تخصیص اولیه یک فایل پیوسته بر روی دیسک استفاده می‌شوند.
.It "D"
این نشان‌دهنده یک مدخل دایرکتوری است.
برخلاف typeflag استاندارد "5" در POSIX، پس از این هدر رکوردهای داده‌ای قرار دارند که نام فایل‌های موجود در دایرکتوری را فهرست می‌کنند.
پیش از هر نام، در صورتی که فایل در این بایگانی ذخیره شده باشد نویسه اسکی "Y" و در غیر این صورت نویسه "N" قرار می‌گیرد.
هر نام به یک بایت تهی ختم می‌شود، و یک بایت تهی اضافی پایان فهرست نام‌ها را مشخص می‌کند.
هدف از این مدخل پشتیبانی از پشتیبان‌گیری‌های افزایشی است؛ برنامه‌ای که از چنین بایگانی بازیابی انجام می‌دهد ممکن است بخواهد فایل‌هایی را از روی دیسک حذف کند که هنگام ایجاد بایگانی در دایرکتوری وجود نداشته‌اند.
.Pp
توجه داشته باشید که typeflag نوع "D" مشخصاً استاندارد POSIX را نقض می‌کند، که الزام می‌دارد با typeflagهای ناشناخته مانند فایل‌های عادی رفتار شود.
در این حالت، بازیابی مدخل "D" به عنوان یک فایل می‌تواند در ایجاد بعدی دایرکتوری هم‌نام اختلال ایجاد کند.
.It "K"
داده‌های این مدخل یک linkname طولانی برای مدخل عادی بعدی است.
.It "L"
داده‌های این مدخل یک نام مسیر (pathname) طولانی برای مدخل عادی بعدی است.
.It "M"
این ادامه آخرین فایل در جلد قبلی است.
بایگانی‌های چندجلدی GNU تضمین می‌کنند که هر جلد با یک هدر مدخل معتبر آغاز شود.
برای اطمینان از این امر، ممکن است یک فایل تقسیم شود، به طوری که بخشی از آن در انتهای یک جلد و بخش دیگر در ابتدای جلد بعدی ذخیره گردد.
پرچم نوع "M" نشان می‌دهد که این مدخل ادامه یک فایل موجود است.
چنین مدخل‌هایی فقط می‌توانند به عنوان مدخل اول یا دوم در یک بایگانی ظاهر شوند (دومی فقط در صورتی که مدخل اول برچسب جلد باشد).
فیلد
.Va size
اندازه این مدخل را مشخص می‌کند.
فیلد
.Va offset
در بایت‌های ۳۶۹-۳۸۰ آفستی را که این قطعه از فایل از آن آغاز می‌شود تعیین می‌کند.
فیلد
.Va realsize
اندازه کل فایل را مشخص می‌نماید (که باید برابر با
.Va size
به علاوه
.Va offset
باشد).
هنگام استخراج، GNU tar بررسی می‌کند که نام فایل در هدر همان نام مورد انتظار باشد، آفست هدر در توالی صحیح قرار داشته باشد، و مجموع آفست و اندازه برابر با realsize باشد.
.It "N"
رکوردهای نوع "N" دیگر توسط GNU tar تولید نمی‌شوند.
آن‌ها شامل فهرستی از فایل‌ها برای تغییر نام یا ایجاد پیوند نمادین پس از استخراج بودند؛ این کار در اصل برای پشتیبانی از نام‌های طولانی استفاده می‌شد.
محتوای این رکورد شرح متنی عملیات‌های لازم است، به فرم
.Dq Rename %s to %s\en
یا
.Dq Symlink %s to %s\en ؛
در هر دو حالت، هر دو نام فایل با استفاده از نحو زبان C استاندارد K&R اسکیپ شده‌اند.
به دلایل امنیتی، رکوردهای "N" امروزه هنگام خواندن بایگانی‌ها معمولاً نادیده گرفته می‌شوند.
.It "S"
این یک فایل عادی
.Dq پراکنده (sparse)
است.
فایل‌های پراکنده به صورت مجموعه‌ای از قطعات ذخیره می‌شوند.
هدر شامل فهرستی از جفت‌های آفست/طول قطعات است.
اگر به بیش از چهار مدخل از این دست نیاز باشد، هدر در صورت لزوم با پسوندهای هدر
.Dq اضافی (extra)
(قالب قدیمی‌تری که دیگر استفاده نمی‌شود) یا پسوندهای
.Dq پراکنده (sparse)
گسترش می‌یابد.
.It "V"
فیلد
.Va name
باید به عنوان نام هدر نوار/جلد تفسیر شود.
این مدخل هنگام استخراج عموماً نادیده گرفته می‌شود.
.El
.It Va magic
فیلد magic شامل پنج نویسه
.Dq ustar
است که پس از آن یک نویسه فاصله قرار دارد.
توجه داشته باشید که بایگانی‌های POSIX ustar دارای یک بایت تهی پایانی هستند.
.It Va version
فیلد version شامل یک نویسه فاصله و به دنبال آن یک بایت تهی است.
توجه داشته باشید که بایگانی‌های POSIX ustar از دو نسخه از رقم اسکی
.Dq 0
استفاده می‌کنند.
.It Va atime , Va ctime
زمان آخرین دسترسی به فایل و زمان آخرین تغییر در اطلاعات فایل، ذخیره‌شده به صورت مبنای هشت همانند
.Va mtime .
.It Va longnames
ظاهراً این فیلد دیگر استفاده نمی‌شود.
.It Sparse Va offset / Va numbytes
هر ساختاری از این نوع، یک قطعه منفرد از یک فایل پراکنده (sparse) را مشخص می‌کند.
این دو فیلد مقادیر را به صورت اعداد مبنای هشت ذخیره می‌کنند.
هر یک از قطعات در بایگانی به مضربی از ۵۱۲ بایت تراز (pad) می‌شوند.
هنگام استخراج، فهرست قطعات از هدر (شامل هرگونه هدر پسوند) جمع‌آوری می‌شود و سپس داده‌ها خوانده شده و در آفست‌های مناسب در فایل نوشته می‌شوند.
.It Va isextended
اگر این مقدار غیر صفر باشد، به دنبال هدر رکوردهای تکمیلی
.Dq هدر پراکنده (sparse header)
خواهند آمد.
هر رکورد از این دست شامل اطلاعات حداکثر ۲۱ بلوک پراکنده اضافی است، همان‌طور که در اینجا نشان داده شده است:
.nf
struct gnu_sparse_header {
	struct {
		char offset[12];
		char numbytes[12];
	} sparse[21];
	char    isextended[1];
	char    padding[7];
};
.fi
.It Va realsize
یک نمایش باینری از اندازه کامل فایل، با بازه‌ای بسیار بزرگ‌تر از اندازه فایل در POSIX.
به ویژه، در فایل‌های نوع
.Cm M ,
مدخل فعلی تنها بخشی از فایل است.
در این حالت، فیلد اندازه در POSIX اندازه این مدخل را نشان می‌دهد؛ فیلد
.Va realsize
اندازه کل فایل را مشخص خواهد کرد.
.El
.Ss "بایگانی‌های pax در گنو تار (GNU tar pax archives)"
ابزار GNU tar از نسخه ۱.۱۴ به بعد هنگام مشخص کردن پرچم
.Fl -posix ,
بایگانی‌هایی با قالب تبادل pax می‌نویسد.
این قالب از قالب تبادل pax از نزدیک پیروی می‌کند، و از برخی برچسب‌های
.Cm SCHILY
استفاده کرده و کلیدواژه‌های جدیدی را برای ذخیره اطلاعات فایل‌های پراکنده معرفی می‌نماید.
سه نسخه از پشتیبانی فایل‌های پراکنده وجود داشته است که به نام‌های
.Dq 0.0 ,
.Dq 0.1
و
.Dq 1.0
شناخته می‌شوند.
.Bl -tag -width indent
.It Cm GNU.sparse.numblocks , Cm GNU.sparse.offset , Cm GNU.sparse.numbytes , Cm GNU.sparse.size
قالب
.Dq 0.0
از یک ویژگی اولیه به نام
.Cm GNU.sparse.numblocks
برای مشخص کردن تعداد بلوک‌های موجود در فایل، یک جفت از
.Cm GNU.sparse.offset
و
.Cm GNU.sparse.numbytes
برای مشخص کردن آفست و اندازه هر بلوک، و یک ویژگی منفرد
.Cm GNU.sparse.size
برای نشان دادن اندازه کامل فایل استفاده می‌کرد.
این مقدار با اندازه موجود در هدر tar یکسان نیست زیرا مقدار اخیر اندازه حفره‌ها را شامل نمی‌شود.
این قالب مستلزم حفظ ترتیب ویژگی‌ها بود و به پذیرش تکرار نام ویژگی‌های یکسان توسط برنامه‌های خواننده متکی بود، که این امر رسماً توسط استانداردها مجاز شناخته نشده است.
.It Cm GNU.sparse.map
قالب
.Dq 0.1
از یک ویژگی منفرد استفاده می‌کرد که فهرستی از اعداد ده‌دهی جداشده با کاما را ذخیره می‌نمود.
هر جفت عدد به ترتیب نشان‌دهنده آفست و اندازه یک بلوک از داده‌ها بود.
اگر بایگانی توسط برنامه‌ای استخراج شود که این پسوند را نمی‌شناسد این روش به خوبی کار نمی‌کند، زیرا بسیاری از پیاده‌سازی‌های pax ویژگی‌های ناشناخته را نادیده گرفته و حذف می‌کنند.
.It Cm GNU.sparse.major , Cm GNU.sparse.minor , Cm GNU.sparse.name , Cm GNU.sparse.realsize
قالب
.Dq 1.0
نقشه بلوک‌های پراکنده را در یک یا چند بلوک ۵۱۲ بایتی ذخیره می‌کند که قبل از داده‌های فایل در بدنه مدخل قرار می‌گیرند.
ویژگی‌های pax وجود این نقشه را (از طریق فیلدهای
.Cm GNU.sparse.major
و
.Cm GNU.sparse.minor )
و اندازه کامل فایل مشخص می‌نمایند.
ویژگی
.Cm GNU.sparse.name
نام واقعی فایل را نگهداری می‌کند.
برای جلوگیری از سردرگمی، نام ذخیره‌شده در هدر عادی tar یک نام دستکاری‌شده است تا خطاهای استخراج برای کاربران آشکار باشد.
.El
.Ss "تار در سولاریس (Solaris Tar)"
ابزار Solaris tar (از نگارش SunOS 5.7 به بعد) از یک قالب
.Dq گسترش‌یافته
پشتیبانی می‌کند که اساساً شبیه به قالب تبادل pax است، با تفاوت‌های زیر:
.Bl -bullet -compact -width indent
.It
ویژگی‌های گسترش‌یافته در مدخلی ذخیره می‌شوند که نوع آن
.Cm X
است، نه
.Cm x
که در قالب تبادل pax به کار می‌رود.
به نظر می‌رسد قالب تفصیلی این مدخل مشابه قالب ارائه‌شده در بالا برای مدخل
.Cm x
باشد.
.It
یک هدر تکمیلی
.Cm A
برای ذخیره یک فهرست کنترل دسترسی (ACL) برای مدخل عادی بعدی استفاده می‌شود.
بدنه این مدخل شامل یک عدد مبنای هشت هفت‌رقمی است که به دنبال آن یک بایت صفر و سپس توضیحات متنی ACL قرار می‌گیرد.
مقدار مبنای هشت، تعداد مدخل‌های ACL به علاوه یک مقدار ثابت است که نوع ACL را مشخص می‌کند: 01000000 برای ACLهای POSIX.1e و 03000000 برای ACLهای NFSv4.
.El
.Ss "تار در ای‌آی‌اکس (AIX Tar)"
ابزار AIX Tar از یک هدر با قالب ustar و نوع
.Cm A
برای ذخیره اطلاعات کدگذاری‌شده ACL استفاده می‌کند.
برخلاف قالب سولاریس، ابزار AIX tar این هدر را پس از بدنه فایل عادی مربوطه می‌نویسد.
نام مسیر در این هدر یا
.Cm NFS4
یا
.Cm AIXC
است تا نوع ACL ذخیره‌شده را نشان دهد.
خودِ ACL در قالب باینری وابسته به پلتفرم ذخیره می‌شود.
.Ss "تار در مک او اس ده (Mac OS X Tar)"
ابزار tar ارائه‌شده در سیستم‌عامل Mac OS X شرکت اپل، بیشتر فایل‌های عادی را به صورت دو فایل جداگانه در بایگانی tar ذخیره می‌کند.
این دو فایل دارای نام یکسانی هستند به جز اینکه در ابتدای آخرین مؤلفه مسیر فایل اول، عبارت
.Dq ._
افزوده می‌شود.
این فایل ویژه، یک حباب باینری کدگذاری‌شده در قالب AppleDouble را با فراداده‌های تکمیلی درباره فایل دوم شامل ACL، ویژگی‌های گسترش‌یافته و منابع ذخیره می‌کند.
برای بازسازی فایل اصلی بر روی دیسک، هر فایل به صورت جداگانه قابل استخراج است و می‌توان از تابع
.Fn copyfile
در Mac OS X برای باز کردن بسته فایل فراداده مجزا و اعمال آن بر روی فایل عادی استفاده کرد.
برعکس، همین تابع گزینه‌ای به نام
.Dq pack
فراهم می‌سازد تا فراداده‌های گسترش‌یافته یک فایل درون یک فایل مجزا کدگذاری شود که سپس محتویات آن می‌تواند در یک بایگانی tar قرار گیرد.
.Pp
توجه داشته باشید که ویژگی‌های گسترش‌یافته اپل با نام‌های فایل طولانی تداخل نامناسبی دارند.
از آنجا که هر فایل با نام کامل ذخیره می‌شود، باید یک مجموعه مجزا از پسوندها در بایگانی برای هر کدام گنجانده شود که این امر سربار مورد نیاز برای فایل‌های با نام‌های طولانی را دو برابر می‌کند.
.Ss "خلاصه کدهای نوع tar (Summary of tar type codes)"
فهرست زیر خلاصه‌ای فشرده از کدهای نوع به‌کاررفته در رکوردهای هدر tar است که توسط پیاده‌سازی‌های گوناگون tar تولید می‌شوند.
جزئیات بیشتر درباره پیاده‌سازی‌های خاص را می‌توان در بالا یافت:
.Bl -tag -compact -width XXX
.It NUL
برنامه‌های اولیه tar یک بایت صفر را برای فایل‌های عادی ذخیره می‌کردند.
.It Cm 0
کد نوع استاندارد POSIX برای یک فایل عادی.
.It Cm 1
کد نوع استاندارد POSIX برای شرح یک پیوند سخت.
.It Cm 2
کد نوع استاندارد POSIX برای شرح یک پیوند نمادین.
.It Cm 3
کد نوع استاندارد POSIX برای یک گره دستگاه کاراکتری.
.It Cm 4
کد نوع استاندارد POSIX برای یک گره دستگاه بلوکی.
.It Cm 5
کد نوع استاندارد POSIX برای یک دایرکتوری.
.It Cm 6
کد نوع استاندارد POSIX برای یک FIFO (لوله نام‌گذاری‌شده).
.It Cm 7
رزرو شده توسط POSIX.
.It Cm 7
در GNU tar برای فایل‌های از پیش تخصیص‌یافته در برخی سیستم‌ها استفاده می‌شود.
.It Cm A
شرح ACL در Solaris tar که پیش از هدر فایل عادی ذخیره می‌شود.
.It Cm A
شرح ACL در AIX tar که پس از بدنه فایل ذخیره می‌شود.
.It Cm D
تخلیه دایرکتوری در GNU tar.
.It Cm K
نام پیوند (linkname) طولانی در GNU tar برای هدر بعدی.
.It Cm L
نام مسیر (pathname) طولانی در GNU tar برای هدر بعدی.
.It Cm M
نشانگر چندجلدی در GNU tar، که مشخص می‌کند این فایل ادامه فایلی از جلد قبلی است.
.It Cm N
پشتیبانی از نام فایل طولانی در GNU tar.
منسوخ شده است.
.It Cm S
فایل عادی پراکنده (sparse) در GNU tar.
.It Cm V
نام هدر نوار/جلد در GNU tar.
.It Cm X
هدر پسوند عمومی در Solaris tar.
.It Cm g
پسوندهای سراسری در قالب تبادل pax استاندارد POSIX.
.It Cm x
پسوندهای اختصاصی هر فایل در قالب تبادل pax استاندارد POSIX.
.El
.Sh "همچنین ببینید (SEE ALSO)"
.Xr ar 1 ,
.Xr pax 1 ,
.Xr tar 1
.Sh "استانداردها (STANDARDS)"
ابزار
.Nm tar
دیگر بخشی از POSIX یا Single Unix Standard نیست.
این ابزار آخرین بار در
.St -susv2
حضور داشت.
در استانداردهای بعدی،
.Xr pax 1
جایگزین آن شده است.
قالب ustar در حال حاضر بخشی از مشخصات ابزار
.Xr pax 1
است.
قالب فایل تبادل pax در استاندارد
.St -p1003.1-2001
معرفی شد.
.Sh "تاریخچه (HISTORY)"
دستور
.Nm tar
نخستین بار در نگارش هفتم یونیکس (Seventh Edition Unix) که در ژانویه ۱۹۷۹ منتشر شد ظاهر گردید.
این دستور جایگزین برنامه
.Nm tp
از نگارش چهارم یونیکس شد که آن نیز به نوبه خود جایگزین برنامه
.Nm tap
از نگارش اول یونیکس شده بود.
پیاده‌سازی در مالکیت عمومی
.Nm pdtar
نوشته John Gilmore (حدود سال ۱۹۸۷) بسیار تأثیرگذار بود و اساس
.Nm GNU tar
(حدود سال ۱۹۸۸) را شکل داد.
ابزار بایگانی
.Nm star
نوشته Joerg Schilling یکی دیگر از برنامه‌های بایگانی متن‌باز (تحت مجوز CDDL، توسعه‌یافته در حدود سال ۱۹۸۵) است که از پشتیبانی کامل قالب تبادل pax بهره می‌برد.
.Pp
این مستندات به عنوان بخشی از پروژه
.Nm libarchive
و
.Nm bsdtar
توسط
.An Tim Kientzle Aq kientzle@FreeBSD.org
نوشته شده است.