oxmc/nexe
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
Files
a2f6492d71ba8ac1662802be9e65bc02821a4fe1
nexe/node_modules/tar/test/fixtures/packtest/star.4.html
T
Craig Condon 9b82355175 ability to build executables
2011-11-26 17:00:12 -06:00

1185 lines
53 KiB
HTML
Raw Blame History

<html>
<head>
<title>Manpage for star.4</title>
<META name="description" content="A html version of the manpage for star.4">
<META name="keywords" content="star.4">
</head>
<body background=corrugated_xxxxxlight_metal.gif>
<PRE>
<!-- Manpage converted by man2html 3.0.1 -->
Schily's USER COMMANDS <B><A HREF="STAR.4.html">STAR(4L)</A></B>
</PRE>
<H2>NAME</H2><PRE>
star - tape archive file format
</PRE>
<H2>DESCRIPTION</H2><PRE>
<B>Tar</B> Archives are layered archives. The basic structure is
defined by the POSIX.1-1988 archive format and documented in
the <B>BASIC</B> <B>TAR</B> <B>HEADER</B> <B>DESCRIPTION</B> section below. The higher
level structure is defined by the POSIX.1-2001 extended
headers and documented in the <B>EXTENDED</B> <B>TAR</B> <B>(PAX)</B> <B>HEADER</B>
<B>STRUCTURE</B> section below. POSIX.1-2001 extended headers are
pseudo files that contain an unlimited number of extended
header keywords and associated values. The header keywords
are documented in the <B>EXTENDED</B> <B>TAR</B> <B>(PAX)</B> <B>HEADER</B> <B>KEYWORDS</B>
section below.
</PRE>
<H2>BASIC TAR HEADER DESCRIPTION</H2><PRE>
Physically, a POSIX.1-1988 <B>tar</B> archive consists of a series
of fixed sized blocks of TBLOCK (512) characters. It con-
tains a series of file entries terminated by a logical
end-of-archive marker, which consists of two blocks of 512
bytes of binary zeroes. Each file entry is represented by a
header block that describes the file followed by one or more
blocks with the content of the file. The length of each file
is rounded up to a multiple of 512 bytes.
A number of TBLOCK sizes blocks are grouped together to a
tape record for physical I/O operations. Each record of <I>n</I>
blocks is written with a single <B><A HREF="write.2.html">write(2)</A></B> operation. On mag-
netic tapes, this results in a single tape record.
The header block is defined in star.h as follows:
/*
* POSIX.1-1988 field size values and magic.
*/
#define TBLOCK 512
#define NAMSIZ 100
#define PFXSIZ 155
#define TMODLEN 8
#define TUIDLEN 8
#define TGIDLEN 8
#define TSIZLEN 12
#define TMTMLEN 12
#define TCKSLEN 8
#define TMAGIC "ustar" /* ustar magic 6 chars + '\0' */
#define TMAGLEN 6 /* "ustar" including '\0' */
#define TVERSION "00"
#define TVERSLEN 2
#define TUNMLEN 32
#define TGNMLEN 32
#define TDEVLEN 8
Joerg Schilling Last change: 05/10/19 1
Schily's USER COMMANDS <B><A HREF="STAR.4.html">STAR(4L)</A></B>
/*
* POSIX.1-1988 typeflag values
*/
#define REGTYPE '0' /* Regular File */
#define AREGTYPE '\0' /* Regular File (outdated) */
#define LNKTYPE '1' /* Hard Link */
#define SYMTYPE '2' /* Symbolic Link */
#define CHRTYPE '3' /* Character Special */
#define BLKTYPE '4' /* Block Special */
#define DIRTYPE '5' /* Directory */
#define FIFOTYPE '6' /* FIFO (named pipe) */
#define CONTTYPE '7' /* Contiguous File */
/*
* POSIX.1-2001 typeflag extensions.
* POSIX.1-2001 calls the extended USTAR format PAX although it is
* definitely derived from and based on USTAR. The reason may be that
* POSIX.1-2001 calls the tar program outdated and lists the
* pax program as the successor.
*/
#define LF_GHDR 'g' /* POSIX.1-2001 global extended header */
#define LF_XHDR 'x' /* POSIX.1-2001 extended header */
See section <B>EXTENDED</B> <B>TAR</B> <B>(PAX)</B> <B>HEADER</B> <B>KEYWORDS</B> for more
information about the structure of a POSIX.1-2001 header.
/*
* star/gnu/Sun tar extensions:
*
* Note that the standards committee allows only capital A through
* capital Z for user-defined expansion. This means that defining
* something as, say '8' is a *bad* idea.
*/
#define LF_ACL 'A' /* Solaris Access Control List */
#define LF_DUMPDIR 'D' /* GNU dump dir */
#define LF_EXTATTR 'E' /* Solaris Extended Attribute File */
#define LF_META 'I' /* Inode (metadata only) no file content */
#define LF_LONGLINK 'K' /* NEXT file has a long linkname */
#define LF_LONGNAME 'L' /* NEXT file has a long name */
#define LF_MULTIVOL 'M' /* Continuation file rest to be skipped */
#define LF_NAMES 'N' /* OLD GNU for names &gt; 100 characters*/
#define LF_SPARSE 'S' /* This is for sparse files */
#define LF_VOLHDR 'V' /* tape/volume header Ignore on extraction */
#define LF_VU_XHDR 'X' /* POSIX.1-2001 xtended (Sun VU version) */
/*
* Definitions for the t_mode field
*/
#define TSUID 04000 /* Set UID on execution */
#define TSGID 02000 /* Set GID on execution */
#define TSVTX 01000 /* On directories, restricted deletion flag */
Joerg Schilling Last change: 05/10/19 2
Schily's USER COMMANDS <B><A HREF="STAR.4.html">STAR(4L)</A></B>
#define TUREAD 00400 /* Read by owner */
#define TUWRITE 00200 /* Write by owner special */
#define TUEXEC 00100 /* Execute/search by owner */
#define TGREAD 00040 /* Read by group */
#define TGWRITE 00020 /* Write by group */
#define TGEXEC 00010 /* Execute/search by group */
#define TOREAD 00004 /* Read by other */
#define TOWRITE 00002 /* Write by other */
#define TOEXEC 00001 /* Execute/search by other */
#define TALLMODES 07777 /* The low 12 bits */
/*
* This is the ustar (Posix 1003.1) header.
*/
struct header {
char t_name[NAMSIZ]; /* 0 Filename */
char t_mode[8]; /* 100 Permissions */
char t_uid[8]; /* 108 Numerical User ID */
char t_gid[8]; /* 116 Numerical Group ID */
char t_size[12]; /* 124 Filesize */
char t_mtime[12]; /* 136 st_mtime */
char t_chksum[8]; /* 148 Checksum */
char t_typeflag; /* 156 Typ of File */
char t_linkname[NAMSIZ]; /* 157 Target of Links */
char t_magic[TMAGLEN]; /* 257 "ustar" */
char t_version[TVERSLEN]; /* 263 Version fixed to 00 */
char t_uname[TUNMLEN]; /* 265 User Name */
char t_gname[TGNMLEN]; /* 297 Group Name */
char t_devmajor[8]; /* 329 Major for devices */
char t_devminor[8]; /* 337 Minor for devices */
char t_prefix[PFXSIZ]; /* 345 Prefix for t_name */
/* 500 End */
char t_mfill[12]; /* 500 Filler up to 512 */
};
/*
* star header specific definitions
*/
#define STMAGIC "tar" /* star magic */
#define STMAGLEN 4 /* "tar" including '\0' */
/*
* This is the new (post Posix 1003.1-1988) xstar header
* defined in 1994.
*
* t_prefix[130] is guaranteed to be ' ' to prevent ustar
* compliant implementations from failing.
* t_mfill &amp; t_xmagic need to be zero for a 100% ustar compliant
* implementation, so setting t_xmagic to
* "tar" should be avoided in the future.
*
Joerg Schilling Last change: 05/10/19 3
Schily's USER COMMANDS <B><A HREF="STAR.4.html">STAR(4L)</A></B>
* A different method to recognize this format is to verify that
* t_prefix[130] is equal to ' ' and
* t_atime[0]/t_ctime[0] is an octal number and
* t_atime[11] is equal to ' ' and
* t_ctime[11] is equal to ' '.
*
* Note that t_atime[11]/t_ctime[11] may be changed in future.
*/
struct xstar_header {
char t_name[NAMSIZ]; /* 0 Filename */
char t_mode[8]; /* 100 Permissions */
char t_uid[8]; /* 108 Numerical User ID */
char t_gid[8]; /* 116 Numerical Group ID */
char t_size[12]; /* 124 Filesize */
char t_mtime[12]; /* 136 st_mtime */
char t_chksum[8]; /* 148 Checksum */
char t_typeflag; /* 156 Typ of File */
char t_linkname[NAMSIZ]; /* 157 Target of Links */
char t_magic[TMAGLEN]; /* 257 "ustar" */
char t_version[TVERSLEN]; /* 263 Version fixed to 00 */
char t_uname[TUNMLEN]; /* 265 User Name */
char t_gname[TGNMLEN]; /* 297 Group Name */
char t_devmajor[8]; /* 329 Major for devices */
char t_devminor[8]; /* 337 Minor for devices */
char t_prefix[131]; /* 345 Prefix for t_name */
char t_atime[12]; /* 476 st_atime */
char t_ctime[12]; /* 488 st_ctime */
char t_mfill[8]; /* 500 Filler up to star magic */
char t_xmagic[4]; /* 508 "tar" */
};
struct sparse {
char t_offset[12];
char t_numbytes[12];
};
#define SPARSE_EXT_HDR 21
struct xstar_ext_header {
struct sparse t_sp[21];
char t_isextended;
};
typedef union hblock {
char dummy[TBLOCK];
long ldummy[TBLOCK/sizeof (long)]; /* force long alignment */
struct header dbuf;
struct xstar_header xstar_dbuf;
struct xstar_ext_header xstar_ext_dbuf;
} TCB;
Joerg Schilling Last change: 05/10/19 4
Schily's USER COMMANDS <B><A HREF="STAR.4.html">STAR(4L)</A></B>
For maximum portability, all fields that contain character
strings should be limited to use the low 7 bits of a charac-
ter.
The <I>name</I>, <I>linkname</I> and <I>prefix</I> field contain character
strings. The strings are null terminated except when they
use the full space of 100 characters for the <I>name</I> or <I>link-</I>
<I>name</I> field or 155 characters for the <I>prefix</I> field.
If the <I>prefix</I> does not start with a null character, then
<I>prefix</I> and <I>name</I> need to be concatenated by using the <I>prefix</I>,
followed a slash character followed by the <I>name</I> field. If a
null character appears in <I>name</I> or <I>prefix</I> before the maximum
size is reached, the field in question is terminated. This
way file names up to 256 characters may be archived. The
<I>prefix</I> is not used together with the <I>linkname</I> field, so the
maximum length of a link name is 100 characters.
The fields <I>magic</I>, <I>uname</I> and <I>gname</I> contain null terminated
character strings.
The version field contains the string <B>"00"</B> without a trail-
ing zero. It cannot be set to different values as POSIX.1-
1988 did not specify a way to handle different version
strings. The <I>typeflag</I> field contains a single character.
All numeric fields contain <I>size</I>-<I>1</I> leading zero-filled
numbers using octal digits. They are followed by one or
more space or null characters. All recent implementations
only use one space or null character at the end of a numeri-
cal field to get maximum space for the octal number. <B>Star</B>
always uses a space character as terminator. Numeric fields
with 8 characters may hold up to 7 octal digits (7777777)
which results is a maximum value of 2097151. Numeric fields
with 12 characters may hold up to 11 octal digits
(77777777777) which results is a maximum value of
8589934591.
<I>Star</I> implements a vendor specific (and thus non-POSIX)
extension to put bigger numbers into the numeric fields.
This is done by using a <B>base</B> <B>256</B> coding. The top bit of the
first character in the appropriate 8 character or 12 charac-
ter field is set to flag non octal coding. If base 256 cod-
ing is in use, then all remaining characters are used to
code the number. This results in 7 base 256 digits in 8
character fields and in 11 base 256 digits in 12 character
fields. All base 256 numbers are two's complement numbers.
A base 256 number in a 8 character field may hold 56 bits, a
base 256 number in a 12 character field may hold 88 bits.
This may extended to 64 bits for 8 character fields and to
95 bits for 12 character fields. For a negative number the
first character currently is set to a value of 255 (all 8
Joerg Schilling Last change: 05/10/19 5
Schily's USER COMMANDS <B><A HREF="STAR.4.html">STAR(4L)</A></B>
bits are set). The rightmost character in a 8 or 12 charac-
ter field contains the least significant base 256 number.
Recent GNU tar versions implement the same extension.
While the POSIX standard makes obvious that the fields <I>mode</I>,
<I>uid</I>, <I>gid</I>, <I>size</I>, <I>chksum</I>, <I>devmajor</I> and <I>devminor</I> should be
treated as unsigned numbers, there is no such definition for
the <I>time</I> field.
The mode field contains 12 bits holding permissions, see
above for the definitions for each of the permission bits.
The <I>uid</I> and <I>gid</I> fields contain the numerical user id of the
file.
The <I>size</I> field contains the size of the file in characters.
If the <I>tar</I> <I>header</I> is followed by file data, then the amount
of data that follows is computed by (<I>size</I> + <I>511</I>) / <I>512</I>.
The <I>mtime</I> filed contains the number of seconds since Jan 1st
1970 00:00 UTC as retrived via <B><A HREF="stat.2.html">stat(2)</A></B> in <I>st</I>_<I>mtime</I>.
The <I>chksum</I> field contains a simple checksum over all bytes
of the header. To compute the value, all characters in the
header are treated as unsigned integers and the characters
in the <I>chksum</I> field are treated as if they were all spaces.
When the computation starts, the checksum value is initial-
ized to 0.
The <I>typeflag</I> field specifies the type of the file that is
archived. If a specific <B>tar</B> implementation does not include
support for a specific typeflag value, this implementation
will extract the unknown file types as if they were plain
files.
<B>'0'</B> <B>REGTYPE</B>
A regular file. If the <I>size</I> field is non zero, then
file data follows the header.
<B>'\0'</B> <B>AREGTYPE</B>
For backwards compatibility with pre POSIX.1-1988 <B>tar</B>
implementations, a nul character is also recognized as
marker for plain files. It is not generated by recent
<B>tar</B> implementations. If the <I>size</I> field is non zero,
then file data follows the header.
<B>'1'</B> <B>LNKTYPE</B>
The file is a hard link to another file. The name of
the file that the file is linked to is in the <I>linkname</I>
part of the header. For <B>tar</B> archives written by pre
POSIX.1-1988 implementations, the <I>size</I> field usually
contains the size of the file and needs to be ignored
Joerg Schilling Last change: 05/10/19 6
Schily's USER COMMANDS <B><A HREF="STAR.4.html">STAR(4L)</A></B>
as no data may follow this header type. For POSIX.1-
1988 compliant archives, the <I>size</I> field needs to be 0.
For POSIX.1-2001 compliant archives, the <I>size</I> field may
be non zero, indicating that file data is included in
the archive.
<B>'2'</B> <B>SYMTYPE</B>
The file is a symbolic link to another file. The name
of the file that the file is linked to is in the <I>link-</I>
<I>name</I> part of the header. The <I>size</I> field needs to be 0.
No file data may follow the header.
<B>'3'</B> <B>CHRTYPE</B>
A character special file. The fields <I>devmajor</I> and <I>dev-</I>
<I>minor</I> contain information that defines the file. The
meaning of the <I>size</I> field is unspecified by the POSIX
standard. No file data may follow the header.
<B>'4'</B> <B>BLKTYPE</B>
A block special file. The fields <I>devmajor</I> and <I>devminor</I>
contain information that defines the file. The meaning
of the <I>size</I> field is unspecified by the POSIX standard.
No file data may follow the header.
<B>'5'</B> <B>DIRTYPE</B>
A directory or sub directory. Old (pre POSIX.1-1988)
<B>tar</B> implementations did use the same <I>typeflag</I> value as
for plain files and added a slash to the name. If the
<I>size</I> field is non zero then it indicates the maximum
size in characters the system may allocate for this
directory. If the <I>size</I> field is 0, then the system
shall not limit the size of the directory. On operating
systems where the disk allocation is not done on a
directory base, the <I>size</I> field is ignored on extrac-
tion. No file data may follow the header.
<B>'6'</B> <B>FIFOTYPE</B>
A named pipe. The meaning of the size field is
unspecified by the POSIX standard. The <I>size</I> field must
be ignored on extraction. No file data may follow the
header.
<B>'7'</B> <B>CONTTYPE</B>
A contiguous file. This is a file that gives special
performance attributes. Operating systems that don't
support this file type extract this file type as plain
files. If the <I>size</I> field is non zero, then file data
follows the header.
<B>'g'</B> <B>GLOBAL</B> <B>POSIX.1-2001</B> <B>HEADER</B>
With POSIX.1-2001 pax archives, this type defines a
global extended header. The <I>size</I> is always non zero
Joerg Schilling Last change: 05/10/19 7
Schily's USER COMMANDS <B><A HREF="STAR.4.html">STAR(4L)</A></B>
and denotes the sum of the length fields in the
extended header data. The data that follows the header
is in the <B>pax</B> <B>extended</B> <B>header</B> format. The extended
header records in this header type affect all following
files in the archive unless they are overwritten by new
values. See <B>EXTENDED</B> <B>TAR</B> <B>(PAX)</B> <B>HEADER</B> <B>FORMAT</B> section
below.
<B>'x'</B> <B>EXTENDED</B> <B>POSIX.1-2001</B> <B>HEADER</B>
With POSIX.1-2001 pax archives, this type defines an
extended header. The <I>size</I> is always non zero and
denotes the sum of the length fields in the extended
header data. The data that follows the header is in
the <B>pax</B> <B>extended</B> <B>header</B> format. The extended header
records in this header type only affect the following
file in the archive. See <B>EXTENDED</B> <B>TAR</B> <B>(PAX)</B> <B>HEADER</B>
<B>FORMAT</B> section below.
<B>'A'</B> <B>-</B> <B>'Z'</B>
Reserved for vendor specific implementations.
<B>'A'</B> A Solaris ACL entry as used by the <B>tar</B> implementation
from Sun. The <I>size</I> is always non zero and denotes the
length of the data that follows the header. <B>Star</B>
currently is not able to handle this header type.
<B>'D'</B> A GNU dump directory. This header type is not created
by <B>star</B> and handled like a directory during an extract
operation, so the content is ignored by <B>star</B>. The <I>size</I>
field denotes the length of the data that follows the
header.
<B>'E'</B> A Solaris Extended Attribute File. The <I>size</I> field
denotes the length of the data that follows the header.
<B>Star</B> currently is not able to handle this header type.
<B>'I'</B> A <B>inode</B> <B>metadata</B> entry. This header type is used by
<B>star</B> to archive inode meta data only. To archive more
inode meta data than possible with a POSIX-1.1988 <B>tar</B>
header, a header with type <B>'I'</B> is usually preceded by a
<B>'x'</B> header. It is used with incremental backups. The
<I>size</I> field holds the length of the file. No file data
follows this header.
<B>'K'</B> A long link name. <B>Star</B> is able to read and write this
type of header. With the <B>xustar</B> and <B>exustar</B> formats,
<B>star</B> prefers to store long link names using the
POSIX.1-2001 method. The <I>size</I> is always non zero and
denotes the length of the long link name including the
trailing null byte. The link name is in the data that
follows the header.
Joerg Schilling Last change: 05/10/19 8
Schily's USER COMMANDS <B><A HREF="STAR.4.html">STAR(4L)</A></B>
<B>'L'</B> A long file name. <B>Star</B> is able to read and write this
type of header. With the <B>xustar</B> and <B>exustar</B> formats,
<B>star</B> prefers to store long file names using the
POSIX.1-2001 method. The <I>size</I> is always non zero and
denotes the length of the long file name including the
trailing null byte. The file name is in the data that
follows the header.
<B>'M'</B> A multi volume continuation entry. It is used by <B>star</B>
to tell the extraction program via the <I>size</I> field when
the next regular archive header will follow. This
allows to start extracting multi volume archives with a
volume number greater than one. It is used by GNU tar
to verify multi volume continuation volumes. Other
fields in the GNU multi volume continuation header are
a result of a GNU tar miss conception and cannot be
used. If the <I>size</I> field is non zero the data following
the header is skipped by <B>star</B> if the volume that starts
with it is mounted as the first volume. This header is
ignored if the volume that starts with it is mounted as
continuation volume.
<B>'N'</B> An outdated linktype used by old GNU tar versions to
store long file names. This type is unsupported by
<B>star</B>.
<B>'S'</B> A sparse file. This header type is used by <B>star</B> and
<B>GNU</B> <B>tar</B>. A sparse header is uses instead of a plain
file header to denote a sparse file that follows.
Directly after the header, a list of sparse hole
descriptors follows followed by the compacted file
data. With <I>star</I> formats, the <I>size</I> field holds a size
that represents the sum of the sparse hole descriptors
plus the size of the compacted file data. This allows
other <B>tar</B> implementations to correctly skip to the next
<B>tar</B> <B>header</B>. With GNU tar, up to 4 sparse hole descrip-
tors fit into the sparse header. Additional hole
descriptors are not needed if the file has less than 4
holes. With GNU tar, the size field breaks general <I>tar</I>
header rules and is meaningless because the size of the
sparse hole descriptors does not count.
<B>'V'</B> A volume header. The <I>name</I> field is is used to hold the
volume name. <B>Star</B> uses the <I>atime</I> field to hold the
volume number in case there is no POSIX.1-2001 extended
header. This header type is used by <B>star</B> and <B>GNU</B> <B>tar</B>.
If the <I>size</I> field is non zero the data following the
header is skipped by <B>star</B>.
<B>'X'</B> A vendor unique variant of the POSIX.1-2001 extended
header type. It has been implemented by Sun many years
before the POSIX.1-2001 standard has been approved.
Joerg Schilling Last change: 05/10/19 9
Schily's USER COMMANDS <B><A HREF="STAR.4.html">STAR(4L)</A></B>
See also the <I>typeflag</I> 'x' header type. <B>Star</B> is able to
read and write this type of header.
</PRE>
<H2>EXTENDED TAR (PAX) HEADER STRUCTURE</H2><PRE>
<B>Block</B> <B>type</B> <B>Description</B>
Ustar Header [typeflag='g'] <I>Global</I> <I>Extended</I> <I>Header</I>
Global Extended Data
Ustar Header [typeflag='h'] <I>Extended</I> <I>Header</I>
Extended Data
Ustar header [typeflag='0'] <I>File</I> <I>with</I> <I>Extended</I> <I>Header</I>
Data for File #1
Ustar header [typeflag='0'] <I>File</I> <I>without</I> <I>Extended</I> <I>Header</I>
Data for File #2
Block of binary zeroes <I>First</I> <I>EOF</I> <I>Block</I>
Block of binary zeroes <I>Second</I> <I>EOF</I> <I>Block</I>
</PRE>
<H2>EXTENDED TAR (PAX) HEADER FORMAT</H2><PRE>
The data block that follows a <B>tar</B> archive header with
<I>typeflag</I> <B>'g'</B> or <B>'x'</B> contains one or more records in the fol-
lowing format:
"%d %s=%s\n", &lt;<I>length</I>&gt;, &lt;<I>keyword</I>&gt;, &lt;<I>value</I>&gt;
Each record starts with a a decimal length field. The length
includes the total size of a record including the length
field itself and the trailing new line.
The <I>keyword</I> may not include an equal sign. All keywords
beginning with lower case letters and digits are reserved
for future use by the POSIX standard.
If the value field is of zero length, it deletes any header
field of the same name that is in effect from the same
extended header or from a previous global header.
Null characters do not delimit any value. The value is only
limited by its implicit length.
</PRE>
<H2>EXTENDED TAR (PAX) HEADER KEYWORDS</H2><PRE>
POSIX.1-2001 extended <B>pax</B> header keywords. All numerical
values are represented as decimal strings. All texts are
represented as 7-bit ascii or UTF-8:
<B>atime</B>
The time from <B>st_atime</B> in sub second granularity. <B>Star</B>
currently supports a nanosecond granularity.
<B>charset</B>
The name of the character set used to encode the data
in the following file(s). This keyword is currently
Joerg Schilling Last change: 05/10/19 10
Schily's USER COMMANDS <B><A HREF="STAR.4.html">STAR(4L)</A></B>
ignored by <B>star</B>.
<B>comment</B>
Any number of characters that �should be treated as
comment. <B>Star</B> ignores the comment as documented by the
POSIX standard.
<B>ctime</B>
The time from <B>st_ctime</B> in sub second granularity. <B>Star</B>
currently supports a nanosecond granularity.
<B>gid</B> The group ID of the group that owns the file. The
argument is a decimal number. This field is used if
the group ID of a file is greater than 2097151 (octal
7777777).
<B>gname</B>
The group name of the following file(s) coded in UTF-8
if the group name does not fit into 323 characters or
cannot be expressed in 7-Bit ASCII.
<B>linkpath</B>
The name of the <I>linkpath</I> coded in UTF-8 if it is longer
than 100 characters or cannot be expressed in 7-Bit
ASCII.
<B>mtime</B>
The time from <B>st_mtime</B> in sub second granularity. <B>Star</B>
currently supports a nanosecond granularity.
<B>path</B> The name of the <I>linkpath</I> coded in UTF-8 if it does not
fit into 100 characters + 155 characters prefix or can-
not be expressed in 7-Bit ASCII.
<B>realtime.</B><I>any</I>
The keywords prefixed by <B>realtime.</B> are reserved for
future standardization.
<B>security.</B><I>any</I>
The keywords prefixed by <B>security.</B> are reserved for
future standardization.
<B>size</B> The size of the file as decimal number if the file size
is greater than 8589934591 (octal 77777777777). The
<B>size</B> keyword may not refer to the real file size but is
related to the size if the file in the archive. See
also <B>SCHILY.realsize</B> for more information.
<B>uid</B> The uid ID of the group that owns the file. The argu-
ment is a decimal number. This field is used if the
uid ID of a file is greater than 2097151 (octal
7777777).
Joerg Schilling Last change: 05/10/19 11
Schily's USER COMMANDS <B><A HREF="STAR.4.html">STAR(4L)</A></B>
<B>uname</B>
The user name of the following file(s) coded in UTF-8
if the user name does not fit into 323 characters or
cannot be expressed in 7-Bit ASCII.
<I>VENDOR</I>.keyword
Any keyword that starts with a vendor name in capital
letters is reserved for vendor specific extensions by
the standard. <B>Star</B> uses a lot of these vendor specific
extension. See below for more informations.
</PRE>
<H2>SCHILY PAX EXTENSION KEYWORDS</H2><PRE>
<B>Star</B> uses own vendor specific extensions. The <B>SCHILY</B> vendor
specific extended <B>pax</B> header keywords are:
<B>SCHILY.acl.access</B>
The ACL for a file.
Since no official backup format for POSIX access con-
trol lists has been defined, <B>star</B> uses the vendor
defined attributes <B>SCHILY.acl.access</B> and
<B>SCHILY.acl.default</B> for storing the <B>ACL</B> and <B>Default</B> <B>ACL</B>
of a file, respectively. The access control lists are
stored in the short text form as defined in <B>POSIX</B>
<B>1003.1e</B> <B>draft</B> <B>standard</B> <B>17</B>.
To each named user <B>ACL</B> entry a fourth colon separated
field field containing the <I>user</I> <I>identifier</I> (<I>UID</I>) of the
associated user is appended. To each named group entry
a fourth colon separated field containing the <I>group</I>
<I>identifier</I> (<I>GID</I>) of the associated group is appended.
(POSIX 1003.1e draft standard 17 allows to add fields
to ACL entries.)
This is an example of the format used for
<B>SCHILY.acl.access</B> (a space has been inserted after the
equal sign and lines are broken [marked with '\' ] for
readability, additional fields in bold):
SCHILY.acl.access= user::rwx,user:lisa:r-x:<B>502</B>, \
group::r-x,group:toolies:rwx:<B>102</B>, \
mask::rwx,other::r--x
The numerical user and group identifiers are essential
when restoring a system completely from a backup, as
initially the name-to-identifier mappings may not be
available, and then file ownership restoration would
not work.
As the archive format that is used for backing up
access control lists is compatible with the <B>pax</B> archive
format, archives created that way can be restored by
Joerg Schilling Last change: 05/10/19 12
Schily's USER COMMANDS <B><A HREF="STAR.4.html">STAR(4L)</A></B>
<B>star</B> or a POSIX.1-2001 compliant <B>pax</B>. Note that pro-
grams other than <B>star</B> will ignore the ACL information.
<B>SCHILY.acl.default</B>
The default ACL for a file. See <B>SCHILY.acl.access</B> for
more information.
This is an example of the format used for
<B>SCHILY.acl.default</B> (a space has been inserted after the
equal sign and lines are broken [marked with '\' ] for
readability, additional fields in bold):
SCHILY.acl.default= user::rwx,user:lisa:r-x:<B>502</B>, \
group::r-x,mask::r-x,other::r-x
<B>SCHILY.ddev</B>
The device ids for names used is the <B>SCHILY.dir</B> dump
directory list from <B>st_dev</B> of the file as decimal
number. The <B>SCHILY.ddev</B> keyword is followed by a space
separated list of device id numbers. Each corresponds
exactly to a name in the list found in <B>SCHILY.dir</B>. If
a specific device id number is repeated, a comma (,)
without a following space may be use to denote that the
current device id number is identical to the previous
number. This keyword is used in <B>dump</B> mode. This key-
word is not yet implemented.
The value is a signed int. An implementation should be
able to handle at least 64 bit values. Note that the
value is signed because POSIX does not specify more
than the type should be an int.
<B>SCHILY.dev</B>
The device id from <B>st_dev</B> of the file as decimal
number. This keyword is used in <B>dump</B> mode.
The value is a signed int. An implementation should be
able to handle at least 64 bit values. Note that the
value is signed because POSIX does not specify more
than the type should be an int.
<B>SCHILY.devmajor</B>
The device major number of the file if it is a charac-
ter or block special file. The argument is a decimal
number. This field is used if the device major of the
file is greater than 2097151 (octal 7777777).
The value is a signed int. An implementation should be
able to handle at least 64 bit values. Note that the
value is signed because POSIX does not specify more
than the type should be an int.
Joerg Schilling Last change: 05/10/19 13
Schily's USER COMMANDS <B><A HREF="STAR.4.html">STAR(4L)</A></B>
<B>SCHILY.devminor</B>
The device minor number of the file if it is a charac-
ter or block special file. The argument is a decimal
number. This field is used if the device minor of the
file is greater than 2097151 (octal 7777777).
The value is a signed int. An implementation should be
able to handle at least 64 bit values. Note that the
value is signed because POSIX does not specify more
than the type should be an int.
<B>SCHILY.dino</B>
The inode numbers for names used is the <B>SCHILY.dir</B> dump
directory list from <B>st_ino</B> of the file as decimal
number. The <B>SCHILY.dino</B> keyword is followed by a space
separated list of inode numbers. Each corresponds
exactly to a name in the list found in <B>SCHILY.dir</B>.
This keyword is used in <B>dump</B> mode.
The values are unsigned int. An implementation should
be able to handle at least 64 bit unsigned values.
<B>SCHILY.dir</B>
A list of filenames (the content) for the current
directory. The names are coded in UTF-8. Each file
name is prefixed by a single character that is used as
a flag. Each file name is limited by a null character.
The null character is directly followed by he flag
character for the next file name in case the list is
not terminated by the current file name. The flag
character must not be a null character. By default, a
^A (octal 001) is used. The following flags are
defined:
<B>\000</B> This is the list terminator character - the second
null byte, see below.
<B>^A</B> The default flag that is used in case the <B>dump</B> <B>dir</B>
features have not been active.
<B>Y</B> A non directory file that is in the current
(incremental) dump.
<B>N</B> A non directory file that is not in the current
(incremental) dump.
<B>D</B> A directory that is in the current (incremental)
dump.
<B>d</B> A directory that is not in the current (incremen-
tal) dump.
Joerg Schilling Last change: 05/10/19 14
Schily's USER COMMANDS <B><A HREF="STAR.4.html">STAR(4L)</A></B>
The list is terminated by two successive null bytes.
The first is the null byte for the last file name. The
second null byte is at the position where a flag char-
acter would be expected, it acts ad a list terminator.
The length tag for the <B>SCHILY.dir</B> data includes both
null bytes.
If a dump mode has been selected that writes compact
complete directory information to the beginning of the
archive, the flag character may contain values dif-
ferent from ^A. <B>Star</B> implementations up to <B>star-1.5</B> do
not include this feature. Tar implementations that
like to read archives that use the <B>SCHILY.dir</B> keyword,
shall not rely on values other than \000 (^@) or \001
(^A).
This keyword is used in <B>dump</B> mode.
<B>SCHILY.fflags</B>
A textual version of the BSD or Linux extended file
flags. As this tag has not yet been documented, please
look into the <B>star</B> source, file <B>fflags.c</B> for more
information.
<B>SCHILY.filetype</B>
A textual version of the real file type of the file.
The following names are used:
<B>unallocated</B> An unknown file type that may
be a result of a <B><A HREF="unlink.2.html">unlink(2)</A></B>
operation. This should never
happen.
<B>regular</B> A regular file.
<B>contiguous</B> A contiguous file. On operating
systems or file systems that
don't support this file type,
it is handled like a regular
file.
<B>symlink</B> A symbolic link to any file
type.
<B>directory</B> A directory.
<B>character</B> <B>special</B> A character special file.
<B>block</B> <B>special</B> A block special file.
<B>fifo</B> A named pipe.
Joerg Schilling Last change: 05/10/19 15
Schily's USER COMMANDS <B><A HREF="STAR.4.html">STAR(4L)</A></B>
<B>socket</B> A UNIX domain socket.
<B>mpx</B> <B>character</B> <B>special</B> A multiplexed character special
file.
<B>mpx</B> <B>block</B> <B>special</B> A multiplexed block special
file.
<B>XENIX</B> <B>nsem</B> A XENIX named semaphore.
<B>XENIX</B> <B>nshd</B> XENIX shared data.
<B>door</B> A Solaris door.
<B>eventcount</B> A UNOS event count.
<B>whiteout</B> A BSD whiteout directory entry.
<B>sparse</B> A sparse regular file.
<B>volheader</B> A volume header.
<B>unknown/bad</B> Any other unknown file type.
This should never happen.
<B>SCHILY.ino</B>
The inode number from <B>st_ino</B> of the file as decimal
number. This keyword is used in <B>dump</B> mode.
The value is an unsigned int. An implementation should
be able to handle at least 64 bit unsigned values.
<B>SCHILY.nlink</B>
The link count of the file as decimal number. This
keyword is used in <B>dump</B> mode.
The value is an unsigned int. An implementation should
be able to handle at least 32 bit unsigned values.
<B>SCHILY.offset</B>
The <B>offset</B> value for a multi volume continuation
header. This keyword is used with multi volume con-
tinuation headers. Multi volume continuation headers
are used to allow to start reading a multi volume
archive past the first volume.
The value is an unsigned int. An implementation should
be able to handle at least 64 bit unsigned values.
<B>SCHILY.realsize</B>
The real size of the file as decimal number. This
Joerg Schilling Last change: 05/10/19 16
Schily's USER COMMANDS <B><A HREF="STAR.4.html">STAR(4L)</A></B>
keyword is used if the real size of the file differs
from the visible size of the file in the archive. The
real file size differs from the size in the archive if
the file type is <B>sparse</B> or if the file is a continua-
tion file on a multi volume archive. In case the
<B>SCHILY.realsize</B> keyword is needed, it must be past any
<B>size</B> keyword in case a <B>size</B> keyword is also present.
The value is an unsigned int. An implementation should
be able to handle at least 64 bit unsigned values.
<B>SCHILY.tarfiletype</B>
The following additional file types are used in
<B>SCHILY.tarfiletype</B>:
<B>hardlink</B>
A hard link to any file type.
<B>dumpdir</B>
A directory with dump entries
<B>multivol</B> <B>continuation</B>
A multi volume continuation for any file type.
<B>meta</B> A meta entry (inode meta data only) for any file
type.
<B>SCHILY.xattr.</B><I>attr</I>
A POSIX.1-2001 coded version of the Linux extended file
attributes. Linux extended file attributes are
name/value pairs. Every attribute <I>name</I> results in a
<B>SCHILY.xattr.</B><I>name</I> tag and the value of the extended
attribute is used as the value of the POSIX.1-2001
header tag. Note that this way of coding is not port-
able across platforms. A version for BSD may be
created but Solaris includes far more features with
extended attribute files than Linux does.
A future version of <B>star</B> will implement a similar
method as the <B>tar</B> program on Solaris currently uses.
When this implementation is ready, the
<B>SCHILY.xattr.</B><I>name</I> feature may be removed in favor of a
truly portable implementation that supports Solaris
also.
</PRE>
<H2>SCHILY 'G'LOBAL PAX EXTENSION KEYWORDS</H2><PRE>
The following <B>star</B> vendor unique extensions may only appear
in <B>'g'lobal</B> extended <B>pax</B> headers:
<B>SCHILY.archtype</B>
The textual version of the archive type used. The
Joerg Schilling Last change: 05/10/19 17
Schily's USER COMMANDS <B><A HREF="STAR.4.html">STAR(4L)</A></B>
textual values used for <B>SCHILY.archtype</B> are the same
names that are used in the <B>star</B> command line options to
set up a specific archive type.
In order to allow archive type recognition from this
keyword, the minimum tape block size must be 2x512
bytes (1024 bytes) and the <B>SCHILY.archtype</B> keyword
needs to be in the first 512 bytes of the content of
the first <B>'g'lobal</B> <B>pax</B> header. Then the first tape
block may be scanned to recognize the archive type.
<B>SCHILY.release</B>
The textual version of the <B>star</B> version string and the
platform name where this <B>star</B> has been compiled. The
same text appears when calling <I>star</I> -<I>version</I>.
<B>SCHILY.volhdr.blockoff</B>
This keyword is used for multi volume archives. It
represents the offset within the whole archive
expressed in 512 byte units.
The value is an unsigned int with a valid range between
1 and infinity. An implementation should be able to
handle at least 64 bit unsigned values.
<B>SCHILY.volhdr.blocksize</B>
The tape blocksize expressed in 512 byte units that was
used when writing the archive.
The value is an unsigned int with a valid range between
1 and infinity. An implementation should be able to
handle at least 31 bit unsigned values.
<B>SCHILY.volhdr.cwd</B>
This keyword is used in dump mode. It is only used to
contain the real backup working directory if the
<B>fs</B>-<B>name=</B> option of star is used to overwrite the
<B>SCHILY.volhdr.filesys</B> value. Overwriting
<B>SCHILY.volhdr.filesys</B> is needed when backups are run on
file system snapshots rather than on the real file sys-
tem.
<B>SCHILY.volhdr.device</B>
This keyword is used in dump mode. It represents the
name of the device that holds the file system data. For
disk based file systems, this is the device name of the
mounted device.
This keyword is optional. It helps to correctly iden-
tify the file system from which this dump has been
made.
Joerg Schilling Last change: 05/10/19 18
Schily's USER COMMANDS <B><A HREF="STAR.4.html">STAR(4L)</A></B>
<B>SCHILY.volhdr.dumpdate</B>
This keyword is used in dump mode. It represents the
time the current dump did start.
<B>SCHILY.volhdr.dumplevel</B>
This keyword is used in dump mode. It represents the
level of the current dump. Dump levels are small
numbers, the lowest possible number is 0. Dump level 0
represents a full backup. Dump level 1 represents a
backup that contains all changes that did occur since
the last level 0 dump. Dump level 2 represents a
backup that contains all changes that did occur since
the last level 1 dump. <B>Star</B> does not specify a maximum
allowed dump level but you should try to keep the
numbers less than 100.
The value is an unsigned int with a valid range between
0 and at least 100.
<B>SCHILY.volhdr.dumptype</B>
This keyword is used in dump mode. If the dump is a
complete dump of a file system, then the argument is
the text <B>full</B>, else the argument is the text <B>partial</B>.
<B>SCHILY.volhdr.filesys</B>
This keyword is used in dump mode. It represents the
top level directory for the file system from which this
dump has been made. If the dump represents a dump that
has an associated level, then the this directory needs
to be identical to the root directory of this file sys-
tem which is the mount point.
<B>SCHILY.volhdr.hostname</B>
This keyword is used in dump mode. The value is
retrieved from <B>gethostname(3)</B> or <B>uname(2)</B>.
<B>SCHILY.volhdr.label</B>
The textual volume label. The volume label must be
identical within a set of multi volume archives.
<B>SCHILY.volhdr.refdate</B>
This keyword is used in dump mode if the current dump
is an incremental dump with a level &gt; 0. It represents
the time the related dump did start.
<B>SCHILY.volhdr.reflevel</B>
This keyword is used in dump mode if the current dump
is an incremental dump with a level &gt; 0. It represents
the level of the related dump. The related dump is the
last dump with a level that is lower that the level of
this dump. If a dump with the level of the current
dump -1 exists, then this is the related dump level.
Joerg Schilling Last change: 05/10/19 19
Schily's USER COMMANDS <B><A HREF="STAR.4.html">STAR(4L)</A></B>
Otherwise, the dump level is decremented until a valid
dump level could be found in the dump database.
The value is an unsigned int with a valid range between
0 and at least 100.
<B>SCHILY.volhdr.tapesize</B>
This keyword is used for multi volume archives and may
be used to verify the volume size on read back. It
represents the tape size expressed in 512 byte units.
If this keyword is set in multi volume mode, the size
of the tape is not autodetected but set from a command
line option.
The value is an unsigned int with a valid range between
1 and infinity. An implementation should be able to
handle at least 64 bit unsigned values.
<B>SCHILY.volhdr.volume</B>
This keyword is used for multi volume archives. It
represents the volume number within a volume set. The
number used for the first volume is 1.
The value is an unsigned int with a valid range between
1 and infinity. An implementation should be able to
handle at least 31 bit unsigned values.
</PRE>
<H2>MULTI VOLUME ARCHIVE HANDLING</H2><PRE>
To be documented in the future.
</PRE>
<H2>SEE ALSO</H2><PRE>
</PRE>
<H2>NOTES</H2><PRE>
</PRE>
<H2>BUGS</H2><PRE>
</PRE>
<H2>AUTHOR</H2><PRE>
Joerg Schilling Last change: 05/10/19 20
</PRE>
<HR>
<ADDRESS>
Man(1) output converted with
<a href="http://www.oac.uci.edu/indiv/ehood/man2html.html">man2html</a>
</ADDRESS>
<p><hr>
<a href="http://www.fhg.de/"><IMG SRC="fhglogr.gif" ALT="FhG " BORDER=0></a>
<a href="http://www.fokus.fraunhofer.de/home/"><IMG SRC="fhlogo.gif" ALT="FhG FOKUS " BORDER=0></a>
<a href="http://www.berlios.de/"><IMG SRC="berliOS_logo.jpg" ALT="BerliOS " BORDER=0 WIDTH=159 HEIGHT=41></a>
<a href="http://cdrecord.berlios.de/old/private/index.html">
<IMG SRC="schilling.gif" ALT="Schily " BORDER=0 WIDTH=41 HEIGHT=54></a>
<a href="http://cdrecord.berlios.de/old/private/index.html">Schily's Home</a>
<a href="ftp://ftp.berlios.de/pub/ved/"><IMG SRC="vedpowered.gif" ALT="VED powered " BORDER=0 ></a>
</body>
</html>
Reference in New Issue View Git Blame Copy Permalink