STAR(4L) Schilys USER COMMANDS STAR(4L)
NAME
star(1,4) - tape archive file(1,n) format
DESCRIPTION
Tar Archives are layered archives. The basic structure is defined by
the POSIX.1-1988 archive format and documented in(1,8) the BASIC TAR HEADER
DESCRIPTION section below. The higher level structure is defined by
the POSIX.1-2001 extended headers and documented in(1,8) the EXTENDED TAR
(PAX) HEADER STRUCTURE 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(1,8)
the EXTENDED TAR (PAX) HEADER KEYWORDS section below.
BASIC TAR HEADER DESCRIPTION
Physically, a POSIX.1-1988 tar archive consists of a series of fixed
sized blocks of TBLOCK (512) characters. It contains a series of file(1,n)
entries terminated by a logical end-of-archive marker, which consists
of two blocks of 512 bytes of binary zeroes. Each file(1,n) entry is repre-
sented by a header block that describes the file(1,n) followed by one or
more blocks with the content of the file. The length of each file(1,n) 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 n blocks is written with a
single write(1,2)(2) operation. On magnetic tapes, this results in(1,8) a single
tape record.
The header block is defined in(1,8) 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(4,5) 6 chars + '\0' */
#define TMAGLEN 6 /* "ustar" including '\0' */
#define TVERSION "00"
#define TVERSLEN 2
#define TUNMLEN 32
#define TGNMLEN 32
#define TDEVLEN 8
/*
* 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(5,8) pipe(2,8)) */
#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 EXTENDED TAR (PAX) HEADER KEYWORDS for more information
about the structure of a POSIX.1-2001 header.
/*
* star(1,4)/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(1,n) content */
#define LF_LONGLINK 'K' /* NEXT file(1,n) has a long linkname */
#define LF_LONGNAME 'L' /* NEXT file(1,n) has a long name */
#define LF_MULTIVOL 'M' /* Continuation file(1,n) rest to be skipped */
#define LF_NAMES 'N' /* OLD GNU for names > 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(1,3,5)) */
/*
* 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 */
#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(1,4) header specific definitions
*/
#define STMAGIC "tar" /* star(1,4) magic(4,5) */
#define STMAGLEN 4 /* "tar" including '\0' */
/*
* This is the new (post Posix 1003.1-1988) xstar header
* defined in(1,8) 1994.
*
* t_prefix[130] is guaranteed to be ' ' to prevent ustar
* compliant implementations from failing.
* t_mfill & t_xmagic need to be zero for a 100% ustar compliant
* implementation, so setting t_xmagic to
* "tar" should be avoided in(1,8) the future.
*
* A different method to recognize this format is to verify(1,8) 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(1,8) 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(1,4) magic(4,5) */
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;
For maximum portability, all fields that contain character strings
should be limited to use the low 7 bits of a character.
The name, linkname and prefix field contain character strings. The
strings are null terminated except when they use the full space of 100
characters for the name or linkname field or 155 characters for the
prefix field.
If the prefix does not start with a null character, then prefix and
name need to be concatenated by using the prefix, followed a slash
character followed by the name field. If a null character appears in(1,8)
name or prefix before the maximum size is reached, the field in(1,8) ques-
tion is terminated. This way file(1,n) names up to 256 characters may be
archived. The prefix is not used together with the linkname field, so
the maximum length of a link(1,2) name is 100 characters.
The fields magic(4,5), uname(1,2) and gname contain null terminated character
strings.
The version(1,3,5) field contains the string(3,n) "00" without a trailing zero. It
cannot be set(7,n,1 builtins) to different values as POSIX.1-1988 did not specify a way
to handle different version(1,3,5) strings. The typeflag field contains a
single character.
All numeric fields contain size-1 leading zero-filled numbers using
octal digits. They are followed by one or more space or null charac-
ters. All recent implementations only use one space or null character
at the end of a numerical field to get maximum space for the octal num-
ber. Star 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.
Star implements a vendor specific (and thus non-POSIX) extension to put
bigger numbers into the numeric fields. This is done by using a base
256 coding. The top bit of the first character in(1,8) the appropriate 8
character or 12 character field is set(7,n,1 builtins) to flag non octal coding. If
base 256 coding is in(1,8) use, then all remaining characters are used to
code the number. This results in(1,8) 7 base 256 digits in(1,8) 8 character
fields and in(1,8) 11 base 256 digits in(1,8) 12 character fields. All base 256
numbers are two's complement numbers. A base 256 number in(1,8) a 8 charac-
ter field may hold 56 bits, a base 256 number in(1,8) 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(7,n,1 builtins) to a value of 255 (all 8 bits are set(7,n,1 builtins)). The
rightmost character in(1,8) a 8 or 12 character 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 mode, uid, gid,
size, chksum, devmajor and devminor should be treated as unsigned num-
bers, there is no such definition for the time(1,2,n) field.
The mode field contains 12 bits holding permissions, see above for the
definitions for each of the permission bits.
The uid and gid fields contain the numerical user id of the file.
The size field contains the size of the file(1,n) in(1,8) characters. If the tar
header is followed by file(1,n) data, then the amount of data that follows
is computed by (size + 511) / 512.
The mtime filed contains the number of seconds since Jan 1st 1970 00:00
UTC as retrived via stat(1,2)(2) in(1,8) st_mtime.
The chksum field contains a simple checksum over all bytes of the
header. To compute the value, all characters in(1,8) the header are treated
as unsigned integers and the characters in(1,8) the chksum field are treated
as if(3,n) they were all spaces. When the computation starts, the checksum
value is initialized to 0.
The typeflag field specifies the type of the file(1,n) that is archived. If
a specific tar implementation does not include support for a specific
typeflag value, this implementation will extract the unknown file(1,n) types
as if(3,n) they were plain files.
'0' REGTYPE
A regular file. If the size field is non zero, then file(1,n) data
follows the header.
'\0' AREGTYPE
For backwards compatibility with pre POSIX.1-1988 tar implemen-
tations, a nul character is also recognized as marker for plain
files. It is not generated by recent tar implementations. If
the size field is non zero, then file(1,n) data follows the header.
'1' LNKTYPE
The file(1,n) is a hard link(1,2) to another file. The name of the file(1,n)
that the file(1,n) is linked to is in(1,8) the linkname part of the
header. For tar archives written by pre POSIX.1-1988 implemen-
tations, the size field usually contains the size of the file(1,n)
and needs to be ignored as no data may follow this header type.
For POSIX.1-1988 compliant archives, the size field needs to be
0. For POSIX.1-2001 compliant archives, the size field may be
non zero, indicating that file(1,n) data is included in(1,8) the archive.
'2' SYMTYPE
The file(1,n) is a symbolic link(1,2) to another file. The name of the
file(1,n) that the file(1,n) is linked to is in(1,8) the linkname part of the
header. The size field needs to be 0. No file(1,n) data may follow
the header.
'3' CHRTYPE
A character special file. The fields devmajor and devminor con-
tain information that defines the file. The meaning of the size
field is unspecified by the POSIX standard. No file(1,n) data may
follow the header.
'4' BLKTYPE
A block special file. The fields devmajor and devminor contain
information that defines the file. The meaning of the size
field is unspecified by the POSIX standard. No file(1,n) data may
follow the header.
'5' DIRTYPE
A directory or sub directory. Old (pre POSIX.1-1988) tar imple-
mentations did use the same typeflag value as for plain files
and added a slash to the name. If the size field is non zero
then it indicates the maximum size in(1,8) characters the system may
allocate for this directory. If the size 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 size field is ignored on extraction. No file(1,n) data may
follow the header.
'6' FIFOTYPE
A named(5,8) pipe. The meaning of the size field is unspecified by
the POSIX standard. The size field must be ignored on extrac-
tion. No file(1,n) data may follow the header.
'7' CONTTYPE
A contiguous file. This is a file(1,n) that gives special perfor-
mance attributes. Operating systems that don't support this
file(1,n) type extract this file(1,n) type as plain files. If the size
field is non zero, then file(1,n) data follows the header.
'g' GLOBAL POSIX.1-2001 HEADER
With POSIX.1-2001 pax archives, this type defines a global
extended header. The size is always non zero and denotes the
sum of the length fields in(1,8) the extended header data. The data
that follows the header is in(1,8) the pax extended header format.
The extended header records in(1,8) this header type affect all fol-
lowing files in(1,8) the archive unless they are overwritten by new
values. See EXTENDED TAR (PAX) HEADER FORMAT section below.
'x' EXTENDED POSIX.1-2001 HEADER
With POSIX.1-2001 pax archives, this type defines an extended
header. The size is always non zero and denotes the sum of the
length fields in(1,8) the extended header data. The data that fol-
lows the header is in(1,8) the pax extended header format. The
extended header records in(1,8) this header type only affect the fol-
lowing file(1,n) in(1,8) the archive. See EXTENDED TAR (PAX) HEADER FOR-
MAT section below.
'A' - 'Z'
Reserved for vendor specific implementations.
'A' A Solaris ACL entry as used by the tar implementation from Sun.
The size is always non zero and denotes the length of the data
that follows the header. Star currently is not able to handle
this header type.
'D' A GNU dump directory. This header type is not created by star(1,4)
and handled like a directory during an extract operation, so the
content is ignored by star(1,4). The size field denotes the length
of the data that follows the header.
'E' A Solaris Extended Attribute File. The size field denotes the
length of the data that follows the header. Star currently is
not able to handle this header type.
'I' A inode metadata entry. This header type is used by star(1,4) to ar-
chive inode meta data only. To archive more inode meta data
than possible with a POSIX-1.1988 tar header, a header with type
'I' is usually preceded by a 'x' header. It is used with incre-
mental backups. The size field holds the length of the file.
No file(1,n) data follows this header.
'K' A long link(1,2) name. Star is able to read(2,n,1 builtins) and write(1,2) this type of
header. With the xustar and exustar formats, star(1,4) prefers to
store long link(1,2) names using the POSIX.1-2001 method. The size
is always non zero and denotes the length of the long link(1,2) name
including the trailing null byte. The link(1,2) name is in(1,8) the data
that follows the header.
'L' A long file(1,n) name. Star is able to read(2,n,1 builtins) and write(1,2) this type of
header. With the xustar and exustar formats, star(1,4) prefers to
store long file(1,n) names using the POSIX.1-2001 method. The size
is always non zero and denotes the length of the long file(1,n) name
including the trailing null byte. The file(1,n) name is in(1,8) the data
that follows the header.
'M' A multi volume continuation entry. It is used by star(1,4) to tell
the extraction program via the size 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(1,8) multi volume continuation volumes.
Other fields in(1,8) the GNU multi volume continuation header are a
result of a GNU tar miss conception and cannot be used. If the
size field is non zero the data following the header is skipped
by star(1,4) if(3,n) the volume that starts with it is mounted as the
first volume. This header is ignored if(3,n) the volume that starts
with it is mounted as continuation volume.
'N' An outdated linktype used by old GNU tar versions to store long
file(1,n) names. This type is unsupported by star(1,4).
'S' A sparse file. This header type is used by star(1,4) and GNU tar. A
sparse header is uses instead of a plain file(1,n) header to denote a
sparse file(1,n) that follows. Directly after the header, a list of
sparse hole descriptors follows followed by the compacted file(1,n)
data. With star(1,4) formats, the size field holds a size that rep-
resents the sum of the sparse hole descriptors plus the size of
the compacted file(1,n) data. This allows other tar implementations
to correctly skip to the next tar header. With GNU tar, up to 4
sparse hole descriptors fit into the sparse header. Additional
hole descriptors are not needed if(3,n) the file(1,n) has less(1,3) than 4
holes. With GNU tar, the size field breaks general tar header
rules and is meaningless because the size of the sparse hole
descriptors does not count.
'V' A volume header. The name field is is used to hold the volume
name. Star uses the atime field to hold the volume number in(1,8)
case there is no POSIX.1-2001 extended header. This header type
is used by star(1,4) and GNU tar. If the size field is non zero the
data following the header is skipped by star(1,4).
'X' 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. See also the typeflag
'x' header type. Star is able to read(2,n,1 builtins) and write(1,2) this type of
header.
EXTENDED TAR (PAX) HEADER STRUCTURE
Block type Description
Ustar Header [typeflag='g'] Global Extended Header
Global Extended Data
Ustar Header [typeflag='h'] Extended Header
Extended Data
Ustar header [typeflag='0'] File with Extended Header
Data for File #1
Ustar header [typeflag='0'] File without Extended Header
Data for File #2
Block of binary zeroes First EOF Block
Block of binary zeroes Second EOF Block
EXTENDED TAR (PAX) HEADER FORMAT
The data block that follows a tar archive header with typeflag 'g' or
'x' contains one or more records in(1,8) the following format:
"%d %s=%s\n", <length>, <keyword>, <value>
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 keyword 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(1,8) 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.
EXTENDED TAR (PAX) HEADER KEYWORDS
POSIX.1-2001 extended pax header keywords. All numerical values are
represented as decimal strings. All texts are represented as 7-bit
ascii(1,7) or UTF-8:
atime The time(1,2,n) from st_atime in(1,8) sub second granularity. Star cur-
rently supports a nanosecond granularity.
charset
The name of the character set(7,n,1 builtins) used to encode the data in(1,8) the
following file(1,n)(s). This keyword is currently ignored by star(1,4).
comment
Any number of characters that should be treated as comment.
Star ignores the comment as documented by the POSIX standard.
ctime The time(1,2,n) from st_ctime in(1,8) sub second granularity. Star cur-
rently supports a nanosecond granularity.
gid The group ID of the group that owns the file. The argument is a
decimal number. This field is used if(3,n) the group ID of a file(1,n) is
greater than 2097151 (octal 7777777).
gname The group name of the following file(1,n)(s) coded in(1,8) UTF-8 if(3,n) the
group name does not fit into 323 characters or cannot be
expressed in(1,8) 7-Bit ASCII.
linkpath
The name of the linkpath coded in(1,8) UTF-8 if(3,n) it is longer than 100
characters or cannot be expressed in(1,8) 7-Bit ASCII.
mtime The time(1,2,n) from st_mtime in(1,8) sub second granularity. Star cur-
rently supports a nanosecond granularity.
path The name of the linkpath coded in(1,8) UTF-8 if(3,n) it does not fit into
100 characters + 155 characters prefix or cannot be expressed in(1,8)
7-Bit ASCII.
realtime.any
The keywords prefixed by realtime. are reserved for future
standardization.
security.any
The keywords prefixed by security. are reserved for future
standardization.
size The size of the file(1,n) as decimal number if(3,n) the file(1,n) size is
greater than 8589934591 (octal 77777777777). The size keyword
may not refer to the real file(1,n) size but is related to the size
if(3,n) the file(1,n) in(1,8) the archive. See also SCHILY.realsize for more
information.
uid The uid ID of the group that owns the file. The argument is a
decimal number. This field is used if(3,n) the uid ID of a file(1,n) is
greater than 2097151 (octal 7777777).
uname(1,2) The user name of the following file(1,n)(s) coded in(1,8) UTF-8 if(3,n) the
user name does not fit into 323 characters or cannot be
expressed in(1,8) 7-Bit ASCII.
VENDOR.keyword
Any keyword that starts with a vendor name in(1,8) capital letters is
reserved for vendor specific extensions by the standard. Star
uses a lot of these vendor specific extension. See below for
more informations.
SCHILY PAX EXTENSION KEYWORDS
Star uses own vendor specific extensions. The SCHILY vendor specific
extended pax header keywords are:
SCHILY.acl.access
The ACL for a file.
Since no official backup format for POSIX access(2,5) control lists
has been defined, star(1,4) uses the vendor defined attributes
SCHILY.acl.access and SCHILY.acl.default for storing the ACL and
Default ACL of a file(1,n), respectively. The access(2,5) control lists
are stored in(1,8) the short text form as defined in(1,8) POSIX 1003.1e
draft standard 17.
To each named(5,8) user ACL entry a fourth colon separated field
field containing the user identifier (UID) of the associated
user is appended. To each named(5,8) group entry a fourth colon sep-
arated field containing the group identifier (GID) of the asso-
ciated 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 SCHILY.acl.access (a
space has been inserted after the equal sign and lines are bro-
ken [marked with '\' ] for readability, additional fields in(1,8)
bold):
SCHILY.acl.access= user::rwx,user:lisa:r-x:502, \
group::r-x,group:toolies:rwx:102, \
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(1,n)
ownership restoration would not work.
As the archive format that is used for backing up access(2,5) control
lists is compatible with the pax archive format, archives cre-
ated that way can be restored by star(1,4) or a POSIX.1-2001 compli-
ant pax. Note that programs other than star(1,4) will ignore the ACL
information.
SCHILY.acl.default
The default ACL for a file. See SCHILY.acl.access for more
information.
This is an example of the format used for SCHILY.acl.default (a
space has been inserted after the equal sign and lines are bro-
ken [marked with '\' ] for readability, additional fields in(1,8)
bold):
SCHILY.acl.default= user::rwx,user:lisa:r-x:502, \
group::r-x,mask::r-x,other::r-x
SCHILY.ddev
The device ids for names used is the SCHILY.dir dump directory
list from st_dev of the file(1,n) as decimal number. The SCHILY.ddev
keyword is followed by a space separated list of device id num-
bers. Each corresponds exactly to a name in(1,8) the list found in(1,8)
SCHILY.dir. If a specific device id number is repeated, a comma
(,) without a following space may be use to denote that the cur-
rent device id number is identical to the previous number. This
keyword is used in(1,8) dump mode. This keyword is not yet used.
SCHILY.dev
The device id from st_dev of the file(1,n) as decimal number. This
keyword is used in(1,8) dump mode.
SCHILY.devmajor
The device major number of the file(1,n) if(3,n) it is a character or
block special file. The argument is a decimal number. This
field is used if(3,n) the device major of the file(1,n) is greater than
2097151 (octal 7777777).
SCHILY.devminor
The device minor number of the file(1,n) if(3,n) it is a character or
block special file. The argument is a decimal number. This
field is used if(3,n) the device minor of the file(1,n) is greater than
2097151 (octal 7777777).
SCHILY.dino
The inode numbers for names used is the SCHILY.dir dump direc-
tory list from st_ino of the file(1,n) as decimal number. The
SCHILY.dino keyword is followed by a space separated list of
inode numbers. Each corresponds exactly to a name in(1,8) the list
found in(1,8) SCHILY.dir. This keyword is used in(1,8) dump mode.
SCHILY.dir
A list of filenames (the content) for the current directory.
The names are coded in(1,8) UTF-8. Each file(1,n) name is prefixed by a
single character that is used as a flag. Each file(1,n) name is lim-
ited by a null character. The null character is directly fol-
lowed by he flag character for the next file(1,n) name in(1,8) case the
list is not terminated by the current file(1,n) name. The flag char-
acter must not be a null character. By default, a ^A (octal
001) is used. The following flags are defined:
\000 This is the list terminator character - the second null
byte, see below.
^A The default flag that is used in(1,8) case the dump dir fea-
tures have not been active.
Y A non directory file(1,n) that is in(1,8) the current (incremental)
dump.
N A non directory file(1,n) that is not in(1,8) the current (incre-
mental) dump.
D A directory that is in(1,8) the current (incremental) dump.
d A directory that is not in(1,8) the current (incremental)
dump.
The list is terminated by two successive null bytes. The first
is the null byte for the last file(1,n) name. The second null byte
is at the position where a flag character would be expected, it
acts ad a list terminator. The length tag for the SCHILY.dir
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 different from ^A. Star implemen-
tations up to star-1.5 do not include this feature. Tar imple-
mentations that like to read(2,n,1 builtins) archives that use the SCHILY.dir
keyword, shall not rely on values other than \000 (^@) or \001
(^A).
This keyword is used in(1,8) dump mode.
SCHILY.fflags
A textual version(1,3,5) of the BSD or Linux extended file(1,n) flags. As
this tag has not yet been documented, please look(1,8,3 Search::Dict) into the star(1,4)
source, file(1,n) fflags.c for more information.
SCHILY.filetype
A textual version(1,3,5) of the real file(1,n) type of the file. The fol-
lowing names are used:
unallocated An unknown file(1,n) type that may be a
result of a unlink(1,2)(2) operation. This
should never happen.
regular A regular file.
contiguous A contiguous file. On operating systems
or file(1,n) systems that don't support this
file(1,n) type, it is handled like a regular
file.
symlink A symbolic link(1,2) to any file(1,n) type.
directory A directory.
character special A character special file.
block special A block special file.
fifo A named(5,8) pipe.
socket(2,7,n) A UNIX domain socket.
mpx character special A multiplexed character special file.
mpx block special A multiplexed block special file.
XENIX nsem A XENIX named(5,8) semaphore.
XENIX nshd XENIX shared data.
door A Solaris door.
eventcount A UNOS event count.
whiteout A BSD whiteout directory entry.
sparse A sparse regular file.
volheader A volume header.
unknown/bad Any other unknown file(1,n) type. This
should never happen.
SCHILY.ino
The inode number from st_ino of the file(1,n) as decimal number.
This keyword is used in(1,8) dump mode.
SCHILY.nlink
The link(1,2) count of the file(1,n) as decimal number. This keyword is
used in(1,8) dump mode.
SCHILY.offset
The offset value for a multi volume continuation header. This
keyword is used with multi volume continuation headers. Multi
volume continuation headers are used to allow to start reading a
multi volume archive past the first volume.
SCHILY.realsize
The real size of the file(1,n) as decimal number. This keyword is
used if(3,n) the real size of the file(1,n) differs from the visible size
of the file(1,n) in(1,8) the archive. The real file(1,n) size differs from the
size in(1,8) the archive if(3,n) the file(1,n) type is sparse or if(3,n) the file(1,n) is
a continuation file(1,n) on a multi volume archive. In case the
SCHILY.realsize keyword is needed, it must be past any size key-
word in(1,8) case a size keyword is also present.
SCHILY.tarfiletype
The following additional file(1,n) types are used in(1,8) SCHILY.tarfile-
type:
hardlink
A hard link(1,2) to any file(1,n) type.
dumpdir
A directory with dump entries
multivol continuation
A multi volume continuation for any file(1,n) type.
meta A meta entry (inode meta data only) for any file(1,n) type.
SCHILY.xattr.attr(1,5)
A POSIX.1-2001 coded version(1,3,5) of the Linux extended file(1,n)
attributes. Linux extended file(1,n) attributes are name/value
pairs. Every attribute name results in(1,8) a SCHILY.xattr.name 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 portable across platforms. A version(1,3,5) for BSD may be created
but Solaris includes far more features with extended attribute
files than Linux does.
A future version(1,3,5) of star(1,4) will implement a similar method as the
tar program on Solaris currently uses. When this implementation
is ready, the SCHILY.xattr.name feature may be removed in(1,8) favor
of a truly portable implementation that supports Solaris also.
SCHILY 'G'LOBAL PAX EXTENSION KEYWORDS
The following star(1,4) vendor unique extensions may only appear in(1,8) 'g'lobal
extended pax headers:
SCHILY.archtype
The textual version(1,3,5) of the archive type used. The textual val-
ues used for SCHILY.archtype are the sam of the content of the
first 'g'lobal pax header. Then the first tape block may be
scanned to recognize the archive type.
SCHILY.release
The textual version(1,3,5) of the star(1,4) version(1,3,5) string(3,n) and the platform
name where this star(1,4) has been compiled. The same text appears
when calling star(1,4) -version.
SCHILY.volhdr.blockoff
This keyword is used for multi volume archives. It represents
the offset within the whole archive expressed in(1,8) 512 byte units.
SCHILY.volhdr.blocksize
The tape blocksize expressed in(1,8) 512 byte units(1,7) that was used
when writing the archive.
SCHILY.volhdr.cwd
This keyword is used in(1,8) dump mode. It is only used to contain
the real backup working directory if(3,n) the fs-name= option of star(1,4)
is used to overwrite the SCHILY.volhdr.filesys value. Overwrit-
ing SCHILY.volhdr.filesys is needed when backups are run on file(1,n)
system snapshots rather than on the real file(1,n) system.
SCHILY.volhdr.device
This keyword is used in(1,8) dump mode. It represents the name of
the device that holds the file(1,n) system data. For disk based file(1,n)
systems, this is the device name of the mounted device.
This keyword is optional. It helps to correctly identify the
file(1,n) system from which this dump has been made.
SCHILY.volhdr.dumpdate
This keyword is used in(1,8) dump mode. It represents the time(1,2,n) the
current dump did start.
SCHILY.volhdr.dumplevel
This keyword is used in(1,8) 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. Star does not specify a maximum allowed dump
level but you should try to keep the numbers less(1,3) than 100.
SCHILY.volhdr.dumptype
This keyword is used in(1,8) dump mode. If the dump is a complete
dump of a file(1,n) system, then the argument is the text full, else
the argument is the text partial.
SCHILY.volhdr.filesys
This keyword is used in(1,8) dump mode. It represents the top level
directory for the file(1,n) 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(1,n) system which is the mount(2,8) point.
SCHILY.volhdr.hostname
This keyword is used in(1,8) dump mode. The value is retrieved from
gethostname(3) or uname(1,2)(2).
SCHILY.volhdr.label
The textual volume label. The volume label must be identical
within a set(7,n,1 builtins) of multi volume archives.
SCHILY.volhdr.refdate
This keyword is used in(1,8) dump mode if(3,n) the current dump is an
incremental dump with a level > 0. It represents the time(1,2,n) the
related dump did start.
SCHILY.volhdr.reflevel
This keyword is used in(1,8) dump mode if(3,n) the current dump is an
incremental dump with a level > 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. Otherwise, the dump level is decremented
until a valid dump level could be found in(1,8) the dump database.
SCHILY.volhdr.volume
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.
MULTI VOLUME ARCHIVE HANDLING
To be documented in(1,8) the future.
SEE ALSO
NOTES
BUGS
AUTHOR
Joerg Schilling 05/05/22 STAR(4L)