1STAR(4L) Schily´s USER COMMANDS STAR(4L)
2
6 star - tape archive file format
7
9 Tar Archives are layered archives. The basic structure is defined by
10 the POSIX.1-1988 archive format and documented in the BASIC TAR HEADER
11 DESCRIPTION section below. The higher level structure is defined by
12 the POSIX.1-2001 extended headers and documented in the EXTENDED TAR
13 (PAX) HEADER STRUCTURE section below. POSIX.1-2001 extended headers
14 are pseudo files that contain an unlimited number of extended header
15 keywords and associated values. The header keywords are documented in
16 the EXTENDED TAR (PAX) HEADER KEYWORDS section below.
17
19 Physically, a POSIX.1-1988 tar archive consists of a series of fixed
20 sized blocks of TBLOCK (512) characters. It contains a series of file
21 entries terminated by a logical end-of-archive marker, which consists
22 of two blocks of 512 bytes of binary zeroes. Each file entry is repre‐
23 sented by a header block that describes the file followed by one or
24 more blocks with the content of the file. The length of each file is
25 rounded up to a multiple of 512 bytes.
26 A number of TBLOCK sizes blocks are grouped together to a tape record
28 for physical I/O operations. Each record of n blocks is written with a
29 single write(2) operation. On magnetic tapes, this results in a single
30 tape record.
31 The header block is defined in star.h as follows:
33 /*
34 * POSIX.1-1988 field size values and magic.
35 */
36 #define TBLOCK 512
37 #define NAMSIZ 100
38 #define PFXSIZ 155
39 #define TMODLEN 8
41 #define TUIDLEN 8
42 #define TGIDLEN 8
43 #define TSIZLEN 12
44 #define TMTMLEN 12
45 #define TCKSLEN 8
46 #define TMAGIC "ustar" /* ustar magic 6 chars + '\0' */
48 #define TMAGLEN 6 /* "ustar" including '\0' */
49 #define TVERSION "00"
50 #define TVERSLEN 2
51 #define TUNMLEN 32
52 #define TGNMLEN 32
53 #define TDEVLEN 8
54 /*
56 * POSIX.1-1988 typeflag values
57 */
58 #define REGTYPE '0' /* Regular File */
59 #define AREGTYPE '\0' /* Regular File (outdated) */
60 #define LNKTYPE '1' /* Hard Link */
61 #define SYMTYPE '2' /* Symbolic Link */
62 #define CHRTYPE '3' /* Character Special */
63 #define BLKTYPE '4' /* Block Special */
64 #define DIRTYPE '5' /* Directory */
65 #define FIFOTYPE '6' /* FIFO (named pipe) */
66 #define CONTTYPE '7' /* Contiguous File */
67 /*
69 * POSIX.1-2001 typeflag extensions.
70 * POSIX.1-2001 calls the extended USTAR format PAX although it is
71 * definitely derived from and based on USTAR. The reason may be that
72 * POSIX.1-2001 calls the tar program outdated and lists the
73 * pax program as the successor.
74 */
75 #define LF_GHDR 'g' /* POSIX.1-2001 global extended header */
76 #define LF_XHDR 'x' /* POSIX.1-2001 extended header */
77 See section EXTENDED TAR (PAX) HEADER KEYWORDS for more information
79 about the structure of a POSIX.1-2001 header.
80 /*
82 * star/gnu/Sun tar extensions:
83 *
84 * Note that the standards committee allows only capital A through
85 * capital Z for user-defined expansion. This means that defining
86 * something as, say '8' is a *bad* idea.
87 */
88 #define LF_ACL 'A' /* Solaris Access Control List */
90 #define LF_DUMPDIR 'D' /* GNU dump dir */
91 #define LF_EXTATTR 'E' /* Solaris Extended Attribute File */
92 #define LF_META 'I' /* Inode (metadata only) no file content */
93 #define LF_LONGLINK 'K' /* NEXT file has a long linkname */
94 #define LF_LONGNAME 'L' /* NEXT file has a long name */
95 #define LF_MULTIVOL 'M' /* Continuation file rest to be skipped */
96 #define LF_NAMES 'N' /* OLD GNU for names > 100 characters */
97 #define LF_SPARSE 'S' /* This is for sparse files */
98 #define LF_VOLHDR 'V' /* tape/volume header Ignore on extraction */
99 #define LF_VU_XHDR 'X' /* POSIX.1-2001 xtended (Sun VU version) */
100 /*
102 * Definitions for the t_mode field
103 */
104 #define TSUID 04000 /* Set UID on execution */
105 #define TSGID 02000 /* Set GID on execution */
106 #define TSVTX 01000 /* On directories, restricted deletion flag */
107 #define TUREAD 00400 /* Read by owner */
108 #define TUWRITE 00200 /* Write by owner special */
109 #define TUEXEC 00100 /* Execute/search by owner */
110 #define TGREAD 00040 /* Read by group */
111 #define TGWRITE 00020 /* Write by group */
112 #define TGEXEC 00010 /* Execute/search by group */
113 #define TOREAD 00004 /* Read by other */
114 #define TOWRITE 00002 /* Write by other */
115 #define TOEXEC 00001 /* Execute/search by other */
116 #define TALLMODES 07777 /* The low 12 bits */
118 /*
120 * This is the ustar (Posix 1003.1) header.
121 */
122 struct header {
123 char t_name[NAMSIZ]; /* 0 Filename */
124 char t_mode[8]; /* 100 Permissions */
125 char t_uid[8]; /* 108 Numerical User ID */
126 char t_gid[8]; /* 116 Numerical Group ID */
127 char t_size[12]; /* 124 Filesize */
128 char t_mtime[12]; /* 136 st_mtime */
129 char t_chksum[8]; /* 148 Checksum */
130 char t_typeflag; /* 156 Typ of File */
131 char t_linkname[NAMSIZ]; /* 157 Target of Links */
132 char t_magic[TMAGLEN]; /* 257 "ustar" */
133 char t_version[TVERSLEN]; /* 263 Version fixed to 00 */
134 char t_uname[TUNMLEN]; /* 265 User Name */
135 char t_gname[TGNMLEN]; /* 297 Group Name */
136 char t_devmajor[8]; /* 329 Major for devices */
137 char t_devminor[8]; /* 337 Minor for devices */
138 char t_prefix[PFXSIZ]; /* 345 Prefix for t_name */
139 /* 500 End */
140 char t_mfill[12]; /* 500 Filler up to 512 */
141 };
142 /*
144 * star header specific definitions
145 */
146 #define STMAGIC "tar" /* star magic */
147 #define STMAGLEN 4 /* "tar" including '\0' */
148 /*
150 * This is the new (post Posix 1003.1-1988) xstar header
151 * defined in 1994.
152 *
153 * t_prefix[130] is guaranteed to be ' ' to prevent ustar
154 * compliant implementations from failing.
155 * t_mfill & t_xmagic need to be zero for a 100% ustar compliant
156 * implementation, so setting t_xmagic to
157 * "tar" should be avoided in the future.
158 *
159 * A different method to recognize this format is to verify that
160 * t_prefix[130] is equal to ' ' and
161 * t_atime[0]/t_ctime[0] is an octal number and
162 * t_atime[11] is equal to ' ' and
163 * t_ctime[11] is equal to ' '.
164 *
165 * Note that t_atime[11]/t_ctime[11] may be changed in future.
166 */
167 struct xstar_header {
168 char t_name[NAMSIZ]; /* 0 Filename */
169 char t_mode[8]; /* 100 Permissions */
170 char t_uid[8]; /* 108 Numerical User ID */
171 char t_gid[8]; /* 116 Numerical Group ID */
172 char t_size[12]; /* 124 Filesize */
173 char t_mtime[12]; /* 136 st_mtime */
174 char t_chksum[8]; /* 148 Checksum */
175 char t_typeflag; /* 156 Typ of File */
176 char t_linkname[NAMSIZ]; /* 157 Target of Links */
177 char t_magic[TMAGLEN]; /* 257 "ustar" */
178 char t_version[TVERSLEN]; /* 263 Version fixed to 00 */
179 char t_uname[TUNMLEN]; /* 265 User Name */
180 char t_gname[TGNMLEN]; /* 297 Group Name */
181 char t_devmajor[8]; /* 329 Major for devices */
182 char t_devminor[8]; /* 337 Minor for devices */
183 char t_prefix[131]; /* 345 Prefix for t_name */
184 char t_atime[12]; /* 476 st_atime */
185 char t_ctime[12]; /* 488 st_ctime */
186 char t_mfill[8]; /* 500 Filler up to star magic */
187 char t_xmagic[4]; /* 508 "tar" */
188 };
189 struct sparse {
191 char t_offset[12];
192 char t_numbytes[12];
193 };
194 #define SPARSE_EXT_HDR 21
196 struct xstar_ext_header {
198 struct sparse t_sp[21];
199 char t_isextended;
200 };
201 typedef union hblock {
203 char dummy[TBLOCK];
204 long ldummy[TBLOCK/sizeof (long)]; /* force long alignment */
205 struct header dbuf;
206 struct xstar_header xstar_dbuf;
207 struct xstar_ext_header xstar_ext_dbuf;
208 } TCB;
209 For maximum portability, all fields that contain character strings
211 should be limited to use the low 7 bits of a character.
212 The name, linkname and prefix field contain character strings. The
214 strings are null terminated except when they use the full space of 100
215 characters for the name or linkname field or 155 characters for the
216 prefix field.
217 If the prefix does not start with a null character, then prefix and
219 name need to be concatenated by using the prefix, followed a slash
220 character followed by the name field. If a null character appears in
221 name or prefix before the maximum size is reached, the field in ques‐
222 tion is terminated. This way file names up to 256 characters may be
223 archived. The prefix is not used together with the linkname field, so
224 the maximum length of a link name is 100 characters.
225 The fields magic, uname and gname contain null terminated character
227 strings.
228 The version field contains the string "00" without a trailing zero. It
230 cannot be set to different values as POSIX.1-1988 did not specify a way
231 to handle different version strings. The typeflag field contains a
232 single character.
233 All numeric fields contain size-1 leading zero-filled numbers using
235 octal digits. They are followed by one or more space or null charac‐
236 ters. All recent implementations only use one space or null character
237 at the end of a numerical field to get maximum space for the octal num‐
238 ber. Star always uses a space character as terminator. Numeric fields
239 with 8 characters may hold up to 7 octal digits (7777777) which results
240 is a maximum value of 2097151. Numeric fields with 12 characters may
241 hold up to 11 octal digits (77777777777) which results is a maximum
242 value of 8589934591.
243 Star implements a vendor specific (and thus non-POSIX) extension to put
245 bigger numbers into the numeric fields. This is done by using a base
246 256 coding. The top bit of the first character in the appropriate 8
247 character or 12 character field is set to flag non octal coding. If
248 base 256 coding is in use, then all remaining characters are used to
249 code the number. This results in 7 base 256 digits in 8 character
250 fields and in 11 base 256 digits in 12 character fields. All base 256
251 numbers are two's complement numbers. A base 256 number in a 8 charac‐
252 ter field may hold 56 bits, a base 256 number in a 12 character field
253 may hold 88 bits. This may extended to 64 bits for 8 character fields
254 and to 95 bits for 12 character fields. For a negative number the first
255 character currently is set to a value of 255 (all 8 bits are set). The
256 rightmost character in a 8 or 12 character field contains the least
257 significant base 256 number. Recent GNU tar versions implement the
258 same extension.
259 While the POSIX standard makes obvious that the fields mode, uid, gid,
261 size, chksum, devmajor and devminor should be treated as unsigned num‐
262 bers, there is no such definition for the time field.
263 The mode field contains 12 bits holding permissions, see above for the
265 definitions for each of the permission bits.
266 The uid and gid fields contain the numerical user id of the file.
268 The size field contains the size of the file in characters. If the tar
270 header is followed by file data, then the amount of data that follows
271 is computed by (size + 511) / 512.
272 The mtime filed contains the number of seconds since Jan 1st 1970 00:00
274 UTC as retrived via stat(2) in st_mtime.
275 The chksum field contains a simple checksum over all bytes of the
277 header. To compute the value, all characters in the header are treated
278 as unsigned integers and the characters in the chksum field are treated
279 as if they were all spaces. When the computation starts, the checksum
280 value is initialized to 0.
281 The typeflag field specifies the type of the file that is archived. If
283 a specific tar implementation does not include support for a specific
284 typeflag value, this implementation will extract the unknown file types
285 as if they were plain files.
286 '0' REGTYPE
288 A regular file. If the size field is non zero, then file data
289 follows the header.
290 '\0' AREGTYPE
292 For backwards compatibility with pre POSIX.1-1988 tar implemen‐
293 tations, a nul character is also recognized as marker for plain
294 files. It is not generated by recent tar implementations. If
295 the size field is non zero, then file data follows the header.
296 '1' LNKTYPE
298 The file is a hard link to another file. The name of the file
299 that the file is linked to is in the linkname part of the
300 header. For tar archives written by pre POSIX.1-1988 implemen‐
301 tations, the size field usually contains the size of the file
302 and needs to be ignored as no data may follow this header type.
303 For POSIX.1-1988 compliant archives, the size field needs to be
304 0. For POSIX.1-2001 compliant archives, the size field may be
305 non zero, indicating that file data is included in the archive.
306 '2' SYMTYPE
308 The file is a symbolic link to another file. The name of the
309 file that the file is linked to is in the linkname part of the
310 header. The size field needs to be 0. No file data may follow
311 the header.
312 '3' CHRTYPE
314 A character special file. The fields devmajor and devminor con‐
315 tain information that defines the file. The meaning of the size
316 field is unspecified by the POSIX standard. No file data may
317 follow the header.
318 '4' BLKTYPE
320 A block special file. The fields devmajor and devminor contain
321 information that defines the file. The meaning of the size
322 field is unspecified by the POSIX standard. No file data may
323 follow the header.
324 '5' DIRTYPE
326 A directory or sub directory. Old (pre POSIX.1-1988) tar imple‐
327 mentations did use the same typeflag value as for plain files
328 and added a slash to the name. If the size field is non zero
329 then it indicates the maximum size in characters the system may
330 allocate for this directory. If the size field is 0, then the
331 system shall not limit the size of the directory. On operating
332 systems where the disk allocation is not done on a directory
333 base, the size field is ignored on extraction. No file data may
334 follow the header.
335 '6' FIFOTYPE
337 A named pipe. The meaning of the size field is unspecified by
338 the POSIX standard. The size field must be ignored on extrac‐
339 tion. No file data may follow the header.
340 '7' CONTTYPE
342 A contiguous file. This is a file that gives special perfor‐
343 mance attributes. Operating systems that don't support this
344 file type extract this file type as plain files. If the size
345 field is non zero, then file data follows the header.
346 'g' GLOBAL POSIX.1-2001 HEADER
348 With POSIX.1-2001 pax archives, this type defines a global
349 extended header. The size is always non zero and denotes the
350 sum of the length fields in the extended header data. The data
351 that follows the header is in the pax extended header format.
352 The extended header records in this header type affect all fol‐
353 lowing files in the archive unless they are overwritten by new
354 values. See EXTENDED TAR (PAX) HEADER FORMAT section below.
355 'x' EXTENDED POSIX.1-2001 HEADER
357 With POSIX.1-2001 pax archives, this type defines an extended
358 header. The size is always non zero and denotes the sum of the
359 length fields in the extended header data. The data that fol‐
360 lows the header is in the pax extended header format. The
361 extended header records in this header type only affect the fol‐
362 lowing file in the archive. See EXTENDED TAR (PAX) HEADER FOR‐
363 MAT section below.
364 'A' - 'Z'
366 Reserved for vendor specific implementations.
367 'A' A Solaris ACL entry as used by the tar implementation from Sun.
369 The size is always non zero and denotes the length of the data
370 that follows the header. Star currently is not able to handle
371 this header type.
372 'D' A GNU dump directory. This header type is not created by star
374 and handled like a directory during an extract operation, so the
375 content is ignored by star. The size field denotes the length
376 of the data that follows the header.
377 'E' A Solaris Extended Attribute File. The size field denotes the
379 length of the data that follows the header. Star currently is
380 not able to handle this header type.
381 'I' A inode metadata entry. This header type is used by star to ar‐
383 chive inode meta data only. To archive more inode meta data
384 than possible with a POSIX-1.1988 tar header, a header with type
385 'I' is usually preceded by a 'x' header. It is used with incre‐
386 mental backups. The size field holds the length of the file.
387 No file data follows this header.
388 'K' A long link name. Star is able to read and write this type of
390 header. With the xustar and exustar formats, star prefers to
391 store long link names using the POSIX.1-2001 method. The size
392 is always non zero and denotes the length of the long link name
393 including the trailing null byte. The link name is in the data
394 that follows the header.
395 'L' A long file name. Star is able to read and write this type of
397 header. With the xustar and exustar formats, star prefers to
398 store long file names using the POSIX.1-2001 method. The size
399 is always non zero and denotes the length of the long file name
400 including the trailing null byte. The file name is in the data
401 that follows the header.
402 'M' A multi volume continuation entry. It is used by star to tell
404 the extraction program via the size field when the next regular
405 archive header will follow. This allows to start extracting
406 multi volume archives with a volume number greater than one. It
407 is used by GNU tar to verify multi volume continuation volumes.
408 Other fields in the GNU multi volume continuation header are a
409 result of a GNU tar miss conception and cannot be used. If the
410 size field is non zero the data following the header is skipped
411 by star if the volume that starts with it is mounted as the
412 first volume. This header is ignored if the volume that starts
413 with it is mounted as continuation volume.
414 'N' An outdated linktype used by old GNU tar versions to store long
416 file names. This type is unsupported by star.
417 'S' A sparse file. This header type is used by star and GNU tar. A
419 sparse header is uses instead of a plain file header to denote a
420 sparse file that follows. Directly after the header, a list of
421 sparse hole descriptors follows followed by the compacted file
422 data. With star formats, the size field holds a size that rep‐
423 resents the sum of the sparse hole descriptors plus the size of
424 the compacted file data. This allows other tar implementations
425 to correctly skip to the next tar header. With GNU tar, up to 4
426 sparse hole descriptors fit into the sparse header. Additional
427 hole descriptors are not needed if the file has less than 4
428 holes. With GNU tar, the size field breaks general tar header
429 rules and is meaningless because the size of the sparse hole
430 descriptors does not count.
431 'V' A volume header. The name field is is used to hold the volume
433 name. Star uses the atime field to hold the volume number in
434 case there is no POSIX.1-2001 extended header. This header type
435 is used by star and GNU tar. If the size field is non zero the
436 data following the header is skipped by star.
437 'X' A vendor unique variant of the POSIX.1-2001 extended header
439 type. It has been implemented by Sun many years before the
440 POSIX.1-2001 standard has been approved. See also the typeflag
441 'x' header type. Star is able to read and write this type of
442 header.
443
445 Block type Description
446 Ustar Header [typeflag='g'] Global Extended Header
448 Global Extended Data
449 Ustar Header [typeflag='h'] Extended Header
450 Extended Data
451 Ustar header [typeflag='0'] File with Extended Header
452 Data for File #1
453 Ustar header [typeflag='0'] File without Extended Header
454 Data for File #2
455 Block of binary zeroes First EOF Block
456 Block of binary zeroes Second EOF Block
457
460 The data block that follows a tar archive header with typeflag 'g' or
461 'x' contains one or more records in the following format:
462 "%d %s=%s\n", <length>, <keyword>, <value>
464 Each record starts with a a decimal length field. The length includes
466 the total size of a record including the length field itself and the
467 trailing new line.
468 The keyword may not include an equal sign. All keywords beginning with
470 lower case letters and digits are reserved for future use by the POSIX
471 standard.
472 If the value field is of zero length, it deletes any header field of
474 the same name that is in effect from the same extended header or from a
475 previous global header.
476 Null characters do not delimit any value. The value is only limited by
478 its implicit length.
479
481 POSIX.1-2001 extended pax header keywords. All numerical values are
482 represented as decimal strings. All texts are represented as 7-bit
483 ascii or UTF-8:
484 atime The time from st_atime in sub second granularity. Star cur‐
486 rently supports a nanosecond granularity.
487 charset
489 The name of the character set used to encode the data in the
490 following file(s). This keyword is currently ignored by star.
491 comment
493 Any number of characters that should be treated as comment.
494 Star ignores the comment as documented by the POSIX standard.
495 ctime The time from st_ctime in sub second granularity. Star cur‐
497 rently supports a nanosecond granularity.
498 gid The group ID of the group that owns the file. The argument is a
500 decimal number. This field is used if the group ID of a file is
501 greater than 2097151 (octal 7777777).
502 gname The group name of the following file(s) coded in UTF-8 if the
504 group name does not fit into 323 characters or cannot be
505 expressed in 7-Bit ASCII.
506 linkpath
508 The name of the linkpath coded in UTF-8 if it is longer than 100
509 characters or cannot be expressed in 7-Bit ASCII.
510 mtime The time from st_mtime in sub second granularity. Star cur‐
512 rently supports a nanosecond granularity.
513 path The name of the linkpath coded in UTF-8 if it does not fit into
515 100 characters + 155 characters prefix or cannot be expressed in
516 7-Bit ASCII.
517 realtime.any
519 The keywords prefixed by realtime. are reserved for future
520 standardization.
521 security.any
523 The keywords prefixed by security. are reserved for future
524 standardization.
525 size The size of the file as decimal number if the file size is
527 greater than 8589934591 (octal 77777777777). The size keyword
528 may not refer to the real file size but is related to the size
529 if the file in the archive. See also SCHILY.realsize for more
530 information.
531 uid The uid ID of the group that owns the file. The argument is a
533 decimal number. This field is used if the uid ID of a file is
534 greater than 2097151 (octal 7777777).
535 uname The user name of the following file(s) coded in UTF-8 if the
537 user name does not fit into 323 characters or cannot be
538 expressed in 7-Bit ASCII.
539 VENDOR.keyword
541 Any keyword that starts with a vendor name in capital letters is
542 reserved for vendor specific extensions by the standard. Star
543 uses a lot of these vendor specific extension. See below for
544 more informations.
545
547 Star uses own vendor specific extensions. The SCHILY vendor specific
548 extended pax header keywords are:
549 SCHILY.acl.access
551 The ACL for a file.
552 Since no official backup format for POSIX access control lists
554 has been defined, star uses the vendor defined attributes
555 SCHILY.acl.access and SCHILY.acl.default for storing the ACL and
556 Default ACL of a file, respectively. The access control lists
557 are stored in the short text form as defined in POSIX 1003.1e
558 draft standard 17.
559 To each named user ACL entry a fourth colon separated field
561 field containing the user identifier (UID) of the associated
562 user is appended. To each named group entry a fourth colon sep‐
563 arated field containing the group identifier (GID) of the asso‐
564 ciated group is appended. (POSIX 1003.1e draft standard 17
565 allows to add fields to ACL entries.)
566 This is an example of the format used for SCHILY.acl.access (a
568 space has been inserted after the equal sign and lines are bro‐
569 ken [marked with '\' ] for readability, additional fields in
570 bold):
571 SCHILY.acl.access= user::rwx,user:lisa:r-x:502, \
573 group::r-x,group:toolies:rwx:102, \
574 mask::rwx,other::r--x
575 The numerical user and group identifiers are essential when
577 restoring a system completely from a backup, as initially the
578 name-to-identifier mappings may not be available, and then file
579 ownership restoration would not work.
580 As the archive format that is used for backing up access control
582 lists is compatible with the pax archive format, archives cre‐
583 ated that way can be restored by star or a POSIX.1-2001 compli‐
584 ant pax. Note that programs other than star will ignore the ACL
585 information.
586 SCHILY.acl.default
588 The default ACL for a file. See SCHILY.acl.access for more
589 information.
590 This is an example of the format used for SCHILY.acl.default (a
592 space has been inserted after the equal sign and lines are bro‐
593 ken [marked with '\' ] for readability, additional fields in
594 bold):
595 SCHILY.acl.default= user::rwx,user:lisa:r-x:502, \
597 group::r-x,mask::r-x,other::r-x
598 SCHILY.acl.type
600 The ACL type used for coding access control lists.
601 The following ACL types are possible:
603 POSIX draft
605 ACLs as defined in POSIX 1003.1e draft standard 17.
606 NFSv4 ACLs as used by NFSv4, NTFS and ZFS.
608 Star currently only implements POSIX draft ACLs. If the
610 SCHILY.acl.type keyword is missing, POSIX draft ACLs are asumed.
611 SCHILY.ddev
613 The device ids for names used is the SCHILY.dir dump directory
614 list from st_dev of the file as decimal number. The SCHILY.ddev
615 keyword is followed by a space separated list of device id num‐
616 bers. Each corresponds exactly to a name in the list found in
617 SCHILY.dir. If a specific device id number is repeated, a comma
618 (,) without a following space may be use to denote that the cur‐
619 rent device id number is identical to the previous number. This
620 keyword is used in dump mode. This keyword is not yet imple‐
621 mented.
622 The value is a signed int. An implementation should be able to
624 handle at least 64 bit values. Note that the value is signed
625 because POSIX does not specify more than the type should be an
626 int.
627 SCHILY.dev
629 The device id from st_dev of the file as decimal number. This
630 keyword is used in dump mode.
631 The value is a signed int. An implementation should be able to
633 handle at least 64 bit values. Note that the value is signed
634 because POSIX does not specify more than the type should be an
635 int.
636 SCHILY.devmajor
638 The device major number of the file if it is a character or
639 block special file. The argument is a decimal number. This
640 field is used if the device major of the file is greater than
641 2097151 (octal 7777777).
642 The value is a signed int. An implementation should be able to
644 handle at least 64 bit values. Note that the value is signed
645 because POSIX does not specify more than the type should be an
646 int.
647 SCHILY.devminor
649 The device minor number of the file if it is a character or
650 block special file. The argument is a decimal number. This
651 field is used if the device minor of the file is greater than
652 2097151 (octal 7777777).
653 The value is a signed int. An implementation should be able to
655 handle at least 64 bit values. Note that the value is signed
656 because POSIX does not specify more than the type should be an
657 int.
658 SCHILY.dino
660 The inode numbers for names used is the SCHILY.dir dump direc‐
661 tory list from st_ino of the file as decimal number. The
662 SCHILY.dino keyword is followed by a space separated list of
663 inode numbers. Each corresponds exactly to a name in the list
664 found in SCHILY.dir. This keyword is used in dump mode.
665 The values are unsigned int. An implementation should be able
667 to handle at least 64 bit unsigned values.
668 SCHILY.dir
670 A list of filenames (the content) for the current directory.
671 The names are coded in UTF-8. Each file name is prefixed by a
672 single character that is used as a flag. Each file name is lim‐
673 ited by a null character. The null character is directly fol‐
674 lowed by he flag character for the next file name in case the
675 list is not terminated by the current file name. The flag char‐
676 acter must not be a null character. By default, a ^A (octal
677 001) is used. The following flags are defined:
678 \000 This is the list terminator character - the second null
680 byte, see below.
681 ^A The default flag that is used in case the dump dir fea‐
683 tures have not been active.
684 Y A non directory file that is in the current (incremental)
686 dump.
687 N A non directory file that is not in the current (incre‐
689 mental) dump.
690 D A directory that is in the current (incremental) dump.
692 d A directory that is not in the current (incremental)
694 dump.
695 The list is terminated by two successive null bytes. The first
697 is the null byte for the last file name. The second null byte
698 is at the position where a flag character would be expected, it
699 acts ad a list terminator. The length tag for the SCHILY.dir
700 data includes both null bytes.
701 If a dump mode has been selected that writes compact complete
703 directory information to the beginning of the archive, the flag
704 character may contain values different from ^A. Star implemen‐
705 tations up to star-1.5 do not include this feature. Tar imple‐
706 mentations that like to read archives that use the SCHILY.dir
707 keyword, shall not rely on values other than \000 (^@) or \001
708 (^A).
709 This keyword is used in dump mode.
711 SCHILY.fflags
713 A textual version of the BSD or Linux extended file flags. As
714 this tag has not yet been documented, please look into the star
715 source, file fflags.c for more information.
716 SCHILY.filetype
718 A textual version of the real file type of the file. The fol‐
719 lowing names are used:
720 unallocated An unknown file type that may be a
722 result of a unlink(2) operation. This
723 should never happen.
724 regular A regular file.
726 contiguous A contiguous file. On operating systems
728 or file systems that don't support this
729 file type, it is handled like a regular
730 file.
731 symlink A symbolic link to any file type.
733 directory A directory.
735 character special A character special file.
737 block special A block special file.
739 fifo A named pipe.
741 socket A UNIX domain socket.
743 mpx character special A multiplexed character special file.
745 mpx block special A multiplexed block special file.
747 XENIX nsem A XENIX named semaphore.
749 XENIX nshd XENIX shared data.
751 door A Solaris door.
753 eventcount A UNOS event count.
755 whiteout A BSD whiteout directory entry.
757 sparse A sparse regular file.
759 volheader A volume header.
761 unknown/bad Any other unknown file type. This
763 should never happen.
764 SCHILY.ino
767 The inode number from st_ino of the file as decimal number.
768 This keyword is used in dump mode.
769 The value is an unsigned int. An implementation should be able
771 to handle at least 64 bit unsigned values.
772 SCHILY.nlink
774 The link count of the file as decimal number. This keyword is
775 used in dump mode.
776 The value is an unsigned int. An implementation should be able
778 to handle at least 32 bit unsigned values.
779 SCHILY.offset
781 The offset value for a multi volume continuation header. This
782 keyword is used with multi volume continuation headers. Multi
783 volume continuation headers are used to allow to start reading a
784 multi volume archive past the first volume.
785 The value is an unsigned int. An implementation should be able
787 to handle at least 64 bit unsigned values.
788 SCHILY.realsize
790 The real size of the file as decimal number. This keyword is
791 used if the real size of the file differs from the visible size
792 of the file in the archive. The real file size differs from the
793 size in the archive if the file type is sparse or if the file is
794 a continuation file on a multi volume archive. In case the
795 SCHILY.realsize keyword is needed, it must be past any size key‐
796 word in case a size keyword is also present.
797 The value is an unsigned int. An implementation should be able
799 to handle at least 64 bit unsigned values.
800 SCHILY.tarfiletype
802 The following additional file types are used in SCHILY.tarfile‐
803 type:
804 hardlink
806 A hard link to any file type.
807 dumpdir
809 A directory with dump entries
810 multivol continuation
812 A multi volume continuation for any file type.
813 meta A meta entry (inode meta data only) for any file type.
815 SCHILY.xattr.attr
817 A POSIX.1-2001 coded version of the Linux extended file
818 attributes. Linux extended file attributes are name/value
819 pairs. Every attribute name results in a SCHILY.xattr.name tag
820 and the value of the extended attribute is used as the value of
821 the POSIX.1-2001 header tag. Note that this way of coding is
822 not portable across platforms. A version for BSD may be created
823 but Solaris includes far more features with extended attribute
824 files than Linux does.
825 A future version of star will implement a similar method as the
827 tar program on Solaris currently uses. When this implementation
828 is ready, the SCHILY.xattr.name feature may be removed in favor
829 of a truly portable implementation that supports Solaris also.
830
833 The following star vendor unique extensions may only appear in 'g'lobal
834 extended pax headers:
835 SCHILY.archtype
837 The textual version of the archive type used. The textual val‐
838 ues used for SCHILY.archtype are the same names that are used in
839 the star command line options to set up a specific archive type.
840 In order to allow archive type recognition from this keyword,
842 the minimum tape block size must be 2x512 bytes (1024 bytes) and
843 the SCHILY.archtype keyword needs to be in the first 512 bytes
844 of the content of the first 'g'lobal pax header. Then the first
845 tape block may be scanned to recognize the archive type.
846 SCHILY.release
848 The textual version of the star version string and the platform
849 name where this star has been compiled. The same text appears
850 when calling star -version.
851 SCHILY.volhdr.blockoff
853 This keyword is used for multi volume archives. It represents
854 the offset within the whole archive expressed in 512 byte units.
855 The value is an unsigned int with a valid range between 1 and
857 infinity. An implementation should be able to handle at least 64
858 bit unsigned values.
859 SCHILY.volhdr.blocksize
861 The tape blocksize expressed in 512 byte units that was used
862 when writing the archive.
863 The value is an unsigned int with a valid range between 1 and
865 infinity. An implementation should be able to handle at least 31
866 bit unsigned values.
867 SCHILY.volhdr.cwd
869 This keyword is used in dump mode. It is only used to contain
870 the real backup working directory if the fs-name= option of star
871 is used to overwrite the SCHILY.volhdr.filesys value. Overwrit‐
872 ing SCHILY.volhdr.filesys is needed when backups are run on file
873 system snapshots rather than on the real file system.
874 SCHILY.volhdr.device
876 This keyword is used in dump mode. It represents the name of
877 the device that holds the file system data. For disk based file
878 systems, this is the device name of the mounted device.
879 This keyword is optional. It helps to correctly identify the
881 file system from which this dump has been made.
882 SCHILY.volhdr.dumpdate
884 This keyword is used in dump mode. It represents the time the
885 current dump did start.
886 SCHILY.volhdr.dumplevel
888 This keyword is used in dump mode. It represents the level of
889 the current dump. Dump levels are small numbers, the lowest
890 possible number is 0. Dump level 0 represents a full backup.
891 Dump level 1 represents a backup that contains all changes that
892 did occur since the last level 0 dump. Dump level 2 represents
893 a backup that contains all changes that did occur since the last
894 level 1 dump. Star does not specify a maximum allowed dump
895 level but you should try to keep the numbers less than 100.
896 The value is an unsigned int with a valid range between 0 and at
898 least 100.
899 SCHILY.volhdr.dumptype
901 This keyword is used in dump mode. If the dump is a complete
902 dump of a file system, then the argument is the text full, else
903 the argument is the text partial.
904 SCHILY.volhdr.filesys
906 This keyword is used in dump mode. It represents the top level
907 directory for the file system from which this dump has been
908 made. If the dump represents a dump that has an associated
909 level, then the this directory needs to be identical to the root
910 directory of this file system which is the mount point.
911 SCHILY.volhdr.hostname
913 This keyword is used in dump mode. The value is retrieved from
914 gethostname(3) or uname(2).
915 SCHILY.volhdr.label
917 The textual volume label. The volume label must be identical
918 within a set of multi volume archives.
919 SCHILY.volhdr.refdate
921 This keyword is used in dump mode if the current dump is an
922 incremental dump with a level > 0. It represents the time the
923 related dump did start.
924 SCHILY.volhdr.reflevel
926 This keyword is used in dump mode if the current dump is an
927 incremental dump with a level > 0. It represents the level of
928 the related dump. The related dump is the last dump with a
929 level that is lower that the level of this dump. If a dump with
930 the level of the current dump -1 exists, then this is the
931 related dump level. Otherwise, the dump level is decremented
932 until a valid dump level could be found in the dump database.
933 The value is an unsigned int with a valid range between 0 and at
935 least 100.
936 SCHILY.volhdr.tapesize
938 This keyword is used for multi volume archives and may be used
939 to verify the volume size on read back. It represents the tape
940 size expressed in 512 byte units. If this keyword is set in
941 multi volume mode, the size of the tape is not autodetected but
942 set from a command line option.
943 The value is an unsigned int with a valid range between 1 and
945 infinity. An implementation should be able to handle at least 64
946 bit unsigned values.
947 SCHILY.volhdr.volume
949 This keyword is used for multi volume archives. It represents
950 the volume number within a volume set. The number used for the
951 first volume is 1.
952 The value is an unsigned int with a valid range between 1 and
954 infinity. An implementation should be able to handle at least 31
955 bit unsigned values.
956
958 To be documented in the future.
959
964Joerg Schilling 09/04/10 STAR(4L)