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 A tar archive consists of a series of 512 byte (TBLOCK) records that
20 are grouped to blocks of typically 20 records (10240 bytes).
21 A number of TBLOCK sizes records are grouped together to a tape block
23 for physical I/O operations. Each block of n records is written with a
24 single write(2) operation. On magnetic tapes, this results in a single
25 tape record in case the tape drive is in variable length record mode.
26 The block structure is only visible on blocked tapes. A larger block
28 size results in higher throughput. Tapes that use a block size larger
29 than 63 kB however may not be readable with any hardware and need to be
30 avoided if read compatibility is important. Older tar implementations
31 do not support block sizes larger than 10240 bytes.
32 For fast backups, it is recommended to use block sizes of at least
34 256 kB and to verify throughput and readability on available hardware.
35 Note that the terms block and record are frequently used inconsistently
37 (starting in the historical documentation from 1979 already) and that
38 the term block is typically used for 512 bytes if the tape block size
39 if not relevant in a specific context.
40
43 Physically, a POSIX.1-1988 tar archive consists of a series of fixed
44 sized blocks of TBLOCK (512) characters. It contains a series of file
45 entries terminated by a logical end-of-archive marker, which consists
46 of two blocks of 512 bytes of binary zeroes. Each file entry is repre‐
47 sented by a header block that describes the file followed by zero or
48 more blocks with the content of the file. The length of each file is
49 rounded up to a multiple of 512 bytes.
50 The header block is defined in star.h as follows:
52 /*
53 * POSIX.1-1988 field size values and magic.
54 */
55 #define TBLOCK 512
56 #define NAMSIZ 100
57 #define PFXSIZ 155
58 #define TMODLEN 8
60 #define TUIDLEN 8
61 #define TGIDLEN 8
62 #define TSIZLEN 12
63 #define TMTMLEN 12
64 #define TCKSLEN 8
65 #define TMAGIC "ustar" /* ustar magic 6 chars + '\0' */
67 #define TMAGLEN 6 /* "ustar" including '\0' */
68 #define TVERSION "00"
69 #define TVERSLEN 2
70 #define TUNMLEN 32
71 #define TGNMLEN 32
72 #define TDEVLEN 8
73 /*
75 * POSIX.1-1988 typeflag values
76 */
77 #define REGTYPE '0' /* Regular File */
78 #define AREGTYPE '\0' /* Regular File (outdated) */
79 #define LNKTYPE '1' /* Hard Link */
80 #define SYMTYPE '2' /* Symbolic Link */
81 #define CHRTYPE '3' /* Character Special */
82 #define BLKTYPE '4' /* Block Special */
83 #define DIRTYPE '5' /* Directory */
84 #define FIFOTYPE '6' /* FIFO (named pipe) */
85 #define CONTTYPE '7' /* Contiguous File */
86 /*
88 * POSIX.1-2001 typeflag extensions.
89 * POSIX.1-2001 calls the extended USTAR format PAX although it is
90 * definitely derived from and based on USTAR. The reason may be that
91 * POSIX.1-2001 calls the tar program outdated and lists the
92 * pax program as the successor.
93 */
94 #define LF_GHDR 'g' /* POSIX.1-2001 global extended header */
95 #define LF_XHDR 'x' /* POSIX.1-2001 extended header */
96 See section EXTENDED TAR (PAX) HEADER KEYWORDS for more information
98 about the structure of a POSIX.1-2001 header.
99 /*
101 * star/gnu/Sun tar extensions:
102 *
103 * Note that the standards committee allows only capital A through
104 * capital Z for user-defined expansion. This means that defining
105 * something as, say '8' is a *bad* idea.
106 */
107 #define LF_ACL 'A' /* Solaris Access Control List */
109 #define LF_DUMPDIR 'D' /* GNU dump dir */
110 #define LF_EXTATTR 'E' /* Solaris Extended Attribute File */
111 #define LF_META 'I' /* Inode (metadata only) no file content */
112 #define LF_LONGLINK 'K' /* NEXT file has a long linkname */
113 #define LF_LONGNAME 'L' /* NEXT file has a long name */
114 #define LF_MULTIVOL 'M' /* Continuation file rest to be skipped */
115 #define LF_NAMES 'N' /* OLD GNU for names > 100 characters */
116 #define LF_SPARSE 'S' /* This is for sparse files */
117 #define LF_VOLHDR 'V' /* tape/volume header Ignore on extraction */
118 #define LF_VU_XHDR 'X' /* POSIX.1-2001 xtended (Sun VU version) */
119 /*
121 * Definitions for the t_mode field
122 */
123 #define TSUID 04000 /* Set UID on execution */
124 #define TSGID 02000 /* Set GID on execution */
125 #define TSVTX 01000 /* On directories, restricted deletion flag */
126 #define TUREAD 00400 /* Read by owner */
127 #define TUWRITE 00200 /* Write by owner special */
128 #define TUEXEC 00100 /* Execute/search by owner */
129 #define TGREAD 00040 /* Read by group */
130 #define TGWRITE 00020 /* Write by group */
131 #define TGEXEC 00010 /* Execute/search by group */
132 #define TOREAD 00004 /* Read by other */
133 #define TOWRITE 00002 /* Write by other */
134 #define TOEXEC 00001 /* Execute/search by other */
135 #define TALLMODES 07777 /* The low 12 bits */
137 /*
139 * This is the ustar (Posix 1003.1) header.
140 */
141 struct header {
142 char t_name[NAMSIZ]; /* 0 Filename */
143 char t_mode[8]; /* 100 Permissions */
144 char t_uid[8]; /* 108 Numerical User ID */
145 char t_gid[8]; /* 116 Numerical Group ID */
146 char t_size[12]; /* 124 Filesize */
147 char t_mtime[12]; /* 136 st_mtime */
148 char t_chksum[8]; /* 148 Checksum */
149 char t_typeflag; /* 156 Typ of File */
150 char t_linkname[NAMSIZ]; /* 157 Target of Links */
151 char t_magic[TMAGLEN]; /* 257 "ustar" */
152 char t_version[TVERSLEN]; /* 263 Version fixed to 00 */
153 char t_uname[TUNMLEN]; /* 265 User Name */
154 char t_gname[TGNMLEN]; /* 297 Group Name */
155 char t_devmajor[8]; /* 329 Major for devices */
156 char t_devminor[8]; /* 337 Minor for devices */
157 char t_prefix[PFXSIZ]; /* 345 Prefix for t_name */
158 /* 500 End */
159 char t_mfill[12]; /* 500 Filler up to 512 */
160 };
161 /*
163 * star header specific definitions
164 */
165 #define STMAGIC "tar" /* star magic */
166 #define STMAGLEN 4 /* "tar" including '\0' */
167 /*
169 * This is the new (post Posix 1003.1-1988) xstar header
170 * defined in 1994.
171 *
172 * t_prefix[130] is guaranteed to be ' ' to prevent ustar
173 * compliant implementations from failing.
174 * t_mfill & t_xmagic need to be zero for a 100% ustar compliant
175 * implementation, so setting t_xmagic to
176 * "tar" should be avoided in the future.
177 *
178 * A different method to recognize this format is to verify that
179 * t_prefix[130] is equal to ' ' and
180 * t_atime[0]/t_ctime[0] is an octal number and
181 * t_atime[11] is equal to ' ' and
182 * t_ctime[11] is equal to ' '.
183 *
184 * Note that t_atime[11]/t_ctime[11] may be changed in future.
185 */
186 struct xstar_header {
187 char t_name[NAMSIZ]; /* 0 Filename */
188 char t_mode[8]; /* 100 Permissions */
189 char t_uid[8]; /* 108 Numerical User ID */
190 char t_gid[8]; /* 116 Numerical Group ID */
191 char t_size[12]; /* 124 Filesize */
192 char t_mtime[12]; /* 136 st_mtime */
193 char t_chksum[8]; /* 148 Checksum */
194 char t_typeflag; /* 156 Typ of File */
195 char t_linkname[NAMSIZ]; /* 157 Target of Links */
196 char t_magic[TMAGLEN]; /* 257 "ustar" */
197 char t_version[TVERSLEN]; /* 263 Version fixed to 00 */
198 char t_uname[TUNMLEN]; /* 265 User Name */
199 char t_gname[TGNMLEN]; /* 297 Group Name */
200 char t_devmajor[8]; /* 329 Major for devices */
201 char t_devminor[8]; /* 337 Minor for devices */
202 char t_prefix[131]; /* 345 Prefix for t_name */
203 char t_atime[12]; /* 476 st_atime */
204 char t_ctime[12]; /* 488 st_ctime */
205 char t_mfill[8]; /* 500 Filler up to star magic */
206 char t_xmagic[4]; /* 508 "tar" */
207 };
208 struct sparse {
210 char t_offset[12];
211 char t_numbytes[12];
212 };
213 #define SPARSE_EXT_HDR 21
215 struct xstar_ext_header {
217 struct sparse t_sp[21];
218 char t_isextended;
219 };
220 typedef union hblock {
222 char dummy[TBLOCK];
223 long ldummy[TBLOCK/sizeof (long)]; /* force long alignment */
224 struct header dbuf;
225 struct xstar_header xstar_dbuf;
226 struct xstar_ext_header xstar_ext_dbuf;
227 } TCB;
228 For maximum portability, all fields that contain character strings
230 should be limited to use the low 7 bits of a character.
231 The name, linkname and prefix field contain character strings. The
233 strings are null terminated except when they use the full space of 100
234 characters for the name or linkname field or 155 characters for the
235 prefix field.
236 If the prefix does not start with a null character, then prefix and
238 name need to be concatenated by using the prefix, followed by a slash
239 character followed by the name field. If a null character appears in
240 name or prefix before the maximum size is reached, the field in ques‐
241 tion is terminated. This way file names up to 256 characters may be
242 archived. The prefix is not used together with the linkname field, so
243 the maximum length of a link name is 100 characters.
244 The fields magic, uname and gname contain null terminated character
246 strings.
247 The version field contains the string "00" without a trailing zero. It
249 cannot be set to different values as POSIX.1-1988 did not specify a way
250 to handle different version strings.
251 The typeflag field contains a single character.
253 All numeric fields contain size-1 leading zero-filled numbers using
255 octal digits. They are followed by one or more space or null charac‐
256 ters. All recent implementations only use one space or null character
257 at the end of a numerical field to get maximum space for the octal num‐
258 ber. Star always uses a space character as terminator. Numeric fields
259 with 8 characters may hold up to 7 octal digits (7777777) which results
260 is a maximum value of 2097151. Numeric fields with 12 characters may
261 hold up to 11 octal digits (77777777777) which results is a maximum
262 value of 8589934591.
263 Star implements a vendor specific (and thus non-POSIX) extension to put
265 bigger numbers into the numeric fields. This is done by using a base
266 256 coding. The top bit of the first character in the appropriate 8
267 character or 12 character field is set to flag non octal coding. If
268 base 256 coding is in use, then all remaining characters are used to
269 code the number. This results in 7 base 256 digits in 8 character
270 fields and in 11 base 256 digits in 12 character fields. All base 256
271 numbers are two's complement numbers. A base 256 number in a 8 charac‐
272 ter field may hold 56 bits, a base 256 number in a 12 character field
273 may hold 88 bits.
274 This may be extended to 63 bits for 8 character fields and to 95 bits
276 for 12 character fields. For a negative number, the first character
277 currently is set to a value of 255 (all 8 bits are set). For a posi‐
278 tive number, the first character currently is set to 128 (the top bit
279 is set and all other bits are cleared).
280 The rightmost character in a 8 or 12 character field contains the least
282 significant base 256 number.
283 Recent GNU tar and BSD libarchive versions implement the same exten‐
285 sion.
286 While the POSIX standard makes it obvious that the fields mode, uid,
288 gid, size, chksum, devmajor and devminor should be treated as unsigned
289 numbers, there is no such definition for the time field.
290 The mode field contains 12 bits holding permissions, see above for the
292 definitions for each of the permission bits.
293 The uid and gid fields contain the numerical user id and group id of
295 the file. These fields may use a base 256 encoding.
296 The size field contains the size of the file in characters. If the tar
298 header is followed by file data, then the amount of data that follows
299 is computed by (size + 511) / 512. This field may use a base 256
300 encoding.
301 The mtime field contains the number of seconds since Jan 1st 1970 00:00
303 UTC as retrieved via stat(2) in st_mtime. If the mtime field is
304 assumed to be a signed 33 bit number, the latest representable time is
305 2106 Feb 7 06:28:15 GMT. This is because POSIX does not mention
306 whether the time has to be a signed or unsigned number and thus no more
307 than 32 bits may be used for a positive value if applications care
308 about portability. This field may use a base 256 encoding.
309 The chksum field contains a simple checksum over all bytes of the
311 header. To compute the value, all characters in the header are treated
312 as unsigned integers and the characters in the chksum field are treated
313 as if they were all spaces. When the computation starts, the checksum
314 value is initialized to 0.
315 The typeflag field specifies the type of the file that is archived. If
317 a specific tar implementation does not include support for a specific
318 typeflag value, this implementation will extract the unknown file types
319 as if they were plain files. For this reason, the size field for any
320 file type except directories, hard links, symbolic links, character
321 special, block specials and FIFOs must always follow the rules for
322 plain files.
323 '0' REGTYPE
325 A regular file. If the size field is non zero, then file data
326 follows the header.
327 '\0' AREGTYPE
329 For backwards compatibility with pre POSIX.1-1988 tar implemen‐
330 tations, a nul character is also recognized as marker for plain
331 files. It is not generated by recent tar implementations. If
332 the size field is non zero, then file data follows the header.
333 '1' LNKTYPE
335 The file is a hard link to another file. The name of the file
336 that the file is linked to is in the linkname part of the
337 header. For tar archives written by pre POSIX.1-1988 implemen‐
338 tations, the size field usually contains the size of the file
339 and needs to be ignored as no data may follow this header type.
340 For POSIX.1-1988 compliant archives, the size field needs to be
341 0. For POSIX.1-2001 compliant archives, the size field may be
342 non zero, indicating that file data is included in the archive.
343 '2' SYMTYPE
345 The file is a symbolic link to another file. The name of the
346 file that the file is linked to is in the linkname part of the
347 header. The size field needs to be 0. No file data may follow
348 the header.
349 '3' CHRTYPE
351 A character special file. The fields devmajor and devminor con‐
352 tain information that defines the device id of the file. The
353 meaning of the size field is unspecified by the POSIX standard.
354 No file data may follow the header.
355 '4' BLKTYPE
357 A block special file. The fields devmajor and devminor contain
358 information that defines the device id of the file. The meaning
359 of the size field is unspecified by the POSIX standard. No file
360 data may follow the header.
361 '5' DIRTYPE
363 A directory or sub directory. Old (pre POSIX.1-1988) tar imple‐
364 mentations did use the same typeflag value as for plain files
365 and added a slash to the end of the name field. If the size
366 field is non zero then it indicates the maximum size in charac‐
367 ters the system may allocate for this directory. If the size
368 field is 0, then the system shall not limit the size of the
369 directory. On operating systems where the disk allocation is not
370 done on a directory base, the size field is ignored on extrac‐
371 tion. No file data may follow the header.
372 '6' FIFOTYPE
374 A named pipe. The meaning of the size field is unspecified by
375 the POSIX standard. The size field must be ignored on extrac‐
376 tion. No file data may follow the header.
377 '7' CONTTYPE
379 A contiguous file. This is a file that gives special perfor‐
380 mance attributes. Operating systems that don't support this
381 file type extract this file type as plain files. If the size
382 field is non zero, then file data follows the header.
383 'g' GLOBAL POSIX.1-2001 HEADER
385 With POSIX.1-2001 pax archives, this type defines a global
386 extended header. The size is always non zero and denotes the
387 sum of the length fields in the extended header data. The data
388 that follows the header is in the pax extended header format.
389 The extended header records in this header type affect all fol‐
390 lowing files in the archive unless they are overwritten by new
391 values. See EXTENDED TAR (PAX) HEADER FORMAT section below.
392 'x' EXTENDED POSIX.1-2001 HEADER
394 With POSIX.1-2001 pax archives, this type defines an extended
395 header. The size is always non zero and denotes the sum of the
396 length fields in the extended header data. The data that fol‐
397 lows the header is in the pax extended header format. The
398 extended header records in this header type only affect the fol‐
399 lowing file in the archive. See EXTENDED TAR (PAX) HEADER FOR‐
400 MAT section below.
401 'A' - 'Z'
403 Reserved for vendor specific implementations.
404 'A' A Solaris ACL entry as used by the tar implementation from Sun.
406 The size is always non zero and denotes the length of the data
407 that follows the header. Star currently is not able to handle
408 this header type. As the ACL data used by this format dos not
409 include the numerical user and group id's, this format is not
410 recommended for archival.
411 'D' A GNU dump directory. This header type is not created by star
413 and handled like a POSIX tzpe '5' directory during an extract
414 operation, so the data content is ignored by star. The size
415 field denotes the length of the data that follows the header.
416 'E' A Solaris Extended Attribute File that is used to archive NFSv4
418 type extended attributes. The size field denotes the length of
419 the data that follows the header. Star currently is not able to
420 handle this header type.
421 'I' A inode metadata entry. This header type is used by star to ar‐
423 chive inode meta data only. To archive more inode meta data
424 than possible with a POSIX-1.1988 tar header, a header with type
425 'I' is usually preceded by a 'x' header. It is used with incre‐
426 mental backups. The size field holds the length of the file.
427 No file data follows this header.
428 'K' A long link name. Star is able to read and write this type of
430 header with the star, xstar and gnutar formats. With the xustar
431 and exustar formats, star prefers to store long link names using
432 the POSIX.1-2001 method. The size is always non zero and
433 denotes the length of the long link target name including the
434 trailing null byte. The link name is in the data that follows
435 the header.
436 'L' A long file name. Star is able to read and write this type of
438 header with the star, xstar and gnutar formats. With the xustar
439 and exustar formats, star prefers to store long file names using
440 the POSIX.1-2001 method. The size is always non zero and
441 denotes the length of the long file name including the trailing
442 null byte. The file name is in the data that follows the header.
443 'M' A multi volume continuation entry. It is used by star to tell
445 the extraction program via the size field when the next regular
446 archive header will follow. This allows to start extracting
447 multi volume archives with a volume number greater than one. It
448 is used by GNU tar to verify multi volume continuation volumes.
449 Other fields in the GNU multi volume continuation header are a
450 result of a GNU tar miss conception and cannot be used in a
451 reliable tar implementation. If the size field is non zero the
452 data following the header is skipped by star if the volume that
453 starts with it is mounted as the first volume. This header is
454 ignored if the volume that starts with it is mounted as continu‐
455 ation volume. Instead, the following data is used as the contin‐
456 uation of the file that is currently extracted.
457 'N' An outdated linktype used by old GNU tar versions to store long
459 file names. This type is unsupported by star.
460 'S' A sparse file. This header type is used by star and GNU tar. A
462 sparse header is used instead of a plain file header to denote a
463 sparse file that follows. Directly after the header, a list of
464 sparse hole descriptors follows followed by the compacted file
465 data. With star formats, the size field holds a size that rep‐
466 resents the sum of the sparse hole descriptors plus the size of
467 the compacted file data. This allows other tar implementations
468 to correctly skip to the next tar header. With GNU tar, up to 4
469 sparse hole descriptors fit into the sparse header. Additional
470 hole descriptors are not needed if the file has less than 4
471 holes. With GNU tar, the size field breaks general tar header
472 rules in case more than 4 sparse hole descriptors are used and
473 is meaningless because the size of the additional sparse hole
474 descriptors used by GNU tar does not count and cannot be deter‐
475 mined before parsing all sparse hole descriptors.
476 'V' A volume header. The name field is is used to hold the volume
478 name. Star uses the atime field to hold the volume number in
479 case there is no POSIX.1-2001 extended header. This header type
480 is used by star and GNU tar. If the size field is non zero the
481 data following the header is skipped by star.
482 'X' A vendor unique variant of the POSIX.1-2001 extended header
484 type. It has been implemented by Sun many years before the
485 POSIX.1-2001 standard has been approved and the POSIX.1-2001 tar
486 extensions are based on this Sun tar extension. See also the
487 typeflag 'x' header type. Star is able to read and write this
488 type of header.
489 The devmajor and devminor fields contain the numerical major() and
491 minor() information that defines the device id of the file from the
492 member st_rdev in struct stat. These fields may use a base 256 encod‐
493 ing.
494
496 Block type Description
497 Ustar Header [typeflag='g'] Global Extended Header
499 Global Extended Data
500 Ustar Header [typeflag='x'] Extended Header
501 Extended Data
502 Ustar header [typeflag='0'] File with Extended Header
503 Data for File #1
504 Ustar header [typeflag='0'] File without Extended Header
505 Data for File #2
506 Block of binary zeroes First EOF Block
507 Block of binary zeroes Second EOF Block
508
511 The data block that follows a tar archive header with typeflag 'g' or
512 'x' contains one or more records in the following format:
513 "%d %s=%s\n", <length>, <keyword>, <value>
515 Each record starts with a a decimal length field. The length includes
517 the total size of a record including the length field itself and the
518 trailing new line.
519 The keyword may not include an equal sign. All keywords beginning with
521 lower case letters and digits are reserved for future use by the POSIX
522 standard.
523 If the value field is of zero length, it deletes any header field of
525 the same name that is in effect from the same extended header or from a
526 previous global header.
527 Null characters do not delimit any value. The data used for value is
529 only limited by its implicit length.
530
532 POSIX.1-2001 extended pax header keywords. All numerical values are
533 represented as decimal strings. All texts are represented as UTF-8 or
534 an unspecified binary format (see hdrcharset keyword) that is expected
535 to be understood by the receiving system:
536 atime The time from st_atime in sub second granularity. Star cur‐
538 rently supports a nanosecond granularity.
539 charset
541 The name of the character set used to encode the data in the
542 following file(s).
543 The following values are supported for charset:
545 ISO-IR 646 1990 ISO/IEC 646:1990
547 ISO-IR 8859 1 1998 ISO/IEC 8859-1:1998
549 ISO-IR 8859 2 1998 ISO/IEC 8859-2:1998
551 ISO-IR 8859 3 1998 ISO/IEC 8859-3:1998
553 ISO-IR 8859 4 1998 ISO/IEC 8859-4:1998
555 ISO-IR 8859 5 1998 ISO/IEC 8859-5:1998
557 ISO-IR 8859 6 1998 ISO/IEC 8859-6:1998
559 ISO-IR 8859 7 1998 ISO/IEC 8859-7:1998
561 ISO-IR 8859 8 1998 ISO/IEC 8859-8:1998
563 ISO-IR 8859 9 1998 ISO/IEC 8859-9:1998
565 ISO-IR 8859 10 1998 ISO/IEC 8859-10:1998
567 ISO-IR 8859 11 1998 ISO/IEC 8859-11:1998
569 ISO-IR 8859 12 1998 ISO/IEC 8859-12:1998
571 ISO-IR 8859 13 1998 ISO/IEC 8859-13:1998
573 ISO-IR 8859 14 1998 ISO/IEC 8859-14:1998
575 ISO-IR 8859 15 1998 ISO/IEC 8859-15:1998
577 ISO-IR 10646 2000 ISO/IEC 10646:2000
579 ISO-IR 10646 2000 UTF-8 ISO/IEC 10646, UTF-8 encoding
581 BINARY None
583 This keyword is currently ignored by star.
585 comment
587 Any number of characters that should be treated as comment.
588 Star ignores the comment as documented by the POSIX standard.
589 ctime The time from st_ctime in sub second granularity. Star cur‐
591 rently supports a nanosecond granularity.
592 gid The group ID of the group that owns the file. The argument is a
594 decimal number. This field is used if the group ID of a file is
595 greater than 2097151 (octal 7777777).
596 gname The group name keyword for the following file(s) is created if
598 the group name does not fit into 32 characters or cannot be
599 expressed in 7-Bit ASCII. It is coded in UTF-8 or (if the hdr‐
600 charset keyword is present) coded to fit the charset value.
601 hdrcharset
603 The name of the character set used to encode the data for the
604 gname, linkpath, path and uname fields in the POSIX.1-2001
605 extended header records and for the gname, uname and path parts
606 in the vendor specific extended header records SCHILY.acl.ace,
607 SCHILY.acl.access, SCHILY.acl.default and SCHILY.dir.
608 The following values are supported for hdrcharset:
610 ISO-IR 10646 2000 UTF-8 ISO/IEC 10646, UTF-8 encoding
612 BINARY None
614 If the binary encoding is selected, the encoding is the same as
616 used by the creating system and it is assumed that the receiving
617 system is able to use the values in that encoding.
618 linkpath
620 The linkpath keyword is created if the linkpath is longer than
621 100 characters or cannot be expressed in 7-Bit ASCII. It is
622 coded in UTF-8 or (if the hdrcharset keyword is present) coded
623 to fit the charset value.
624 mtime The time from st_mtime in sub second granularity. Star cur‐
626 rently supports a nanosecond granularity.
627 path The path keyword is created if the path does not fit into 100
629 characters + 155 characters prefix or cannot be expressed in
630 7-Bit ASCII. It is coded in UTF-8 or (if the hdrcharset keyword
631 is present) coded to fit the charset value.
632 realtime.any
634 The keywords prefixed by realtime. are reserved for future
635 standardization.
636 security.any
638 The keywords prefixed by security. are reserved for future
639 standardization.
640 size The size of the file as decimal number if the file size is
642 greater than 8589934591 (octal 77777777777). The size keyword
643 may not refer to the real file size but is related to the size
644 if the file in the archive. See also SCHILY.realsize for more
645 information.
646 uid The uid ID of the group that owns the file. The argument is a
648 decimal number. This field is used if the uid ID of a file is
649 greater than 2097151 (octal 7777777).
650 uname The user name keyword for the following file(s) is created if
652 the user name does not fit into 32 characters or cannot be
653 expressed in 7-Bit ASCII. It is coded in UTF-8 or (if the hdr‐
654 charset keyword is present) coded to fit the charset value.
655 VENDOR.keyword
657 Any keyword that starts with a vendor name in capital letters is
658 reserved for vendor specific extensions by the standard. Star
659 uses a lot of these vendor specific extension. See below for
660 more informations.
661
663 Star uses own vendor specific extensions. The SCHILY vendor specific
664 extended pax header keywords are:
665 SCHILY.acl.ace
667 The NFSv4 ACL for a file.
668 Since no official backup format for the NFSv4 ACL standard has
670 been defined, star uses the vendor defined attributes
671 SCHILY.acl.ace for storing the NFSv4 ACL entries.
672 Previous versions of star used a format for the ACL text that is
674 is the format created by the function acl_totext() from libsec
675 on Solaris, using the call:
676 acl_totext(aclp, \
678 ACL_COMPACT_FMT | ACL_APPEND_ID | ACL_SID_FMT);
679 The flags have the following meaning:
681 ACL_COMPACT_FMT
683 Create the compact version of the ACL text representa‐
684 tion.
685 ACL_APPEND_ID
687 Append uid or gid for additional user or group entries.
688 ACL_SID_FMT
690 Use the usersid or groupsid format for entries related to
691 an ephemeral uid or gid. The raw sid format will only be
692 used when the "id" cannot be resolved to a windows name.
693 This is an example of the format used for SCHILY.acl.ace (a
695 space has been inserted after the equal sign and lines are bro‐
696 ken [marked with '\' ] for readability):
697 SCHILY.acl.ace= user:lisa:rwx-----------:-------:allow:502, \
699 group:toolies:rwx-----------:-------:allow:102, \
700 owner@:--x-----------:-------:deny, \
701 owner@:rw-p---A-W-Co-:-------:allow, \
702 group@:-wxp----------:-------:deny, \
703 group@:r-------------:-------:allow, \
704 everyone@:-wxp---A-W-Co-:-------:deny, \
705 everyone@:r-----a-R-c--s:-------:allow
706 The numerical user and group identifiers are essential when
708 restoring a system completely from a backup, as initially the
709 name-to-identifier mappings may not be available, and then file
710 ownership restoration would not work.
711 Newer versions of star use a highly compact variant of the for‐
713 mat mentioned above that avoids the '-' characters in the text.
714 The example below is using lines broken the same way as in the
715 previous example.
716 SCHILY.acl.ace= user:lisa:rwx::allow:502, \
718 group:toolies:rwx::allow:102, \
719 owner@:x::deny, \
720 owner@:rwpAWCo::allow, \
721 group@:wxp::deny, \
722 group@:r::allow, \
723 everyone@:wxpAWCo::deny, \
724 everyone@:raRcs::allow
725 This highly compact format is understood by acl_fromtext() in
727 libsec from Solaris and by the corresponding code from FreeBSD.
728 It is created by removing the '-' characters from the normal
729 compact format.
730 The advantage of th highly compact format is that it typically
732 avoids the need to make the extended header data larger than 512
733 bytes.
734 In addition to the documented entry formats, a compatible imple‐
736 mentation needs to be able to understand the long ace format, if
737 it appears in extended tar headers. The long format for the ACL
738 text is the format created by the function acl_totext() from
739 libsec on Solaris, using the call:
740 acl_totext(aclp, ACL_APPEND_ID | ACL_SID_FMT);
742 As the archive format that is used for backing up access control
745 lists is compatible with the pax archive format, archives cre‐
746 ated that way can be restored by star or a POSIX.1-2001 compli‐
747 ant pax. Note that programs that do not implement compatibility
748 to the star extensions will ignore the ACL information.
749 SCHILY.acl.access
752 The withdrawn POSIX draft ACL for a file.
753 Since no official backup format for the withdrawn POSIX draft
755 access control lists has been defined, star uses the vendor
756 defined attributes SCHILY.acl.access and SCHILY.acl.default for
757 storing the ACL and Default ACL of a file, respectively. The
758 access control lists are stored in the short text form as
759 defined in the withdrawn POSIX 1003.1e draft standard 17.
760 Note that the POSIX 1003.1e draft has been withdrawn in 1997 but
762 some operating systems still support it with some filesystems.
763 To each named user ACL entry a fourth colon separated field,
765 containing the user identifier (UID) of the associated user, is
766 appended. To each named group entry a fourth colon separated
767 field containing the group identifier (GID) of the associated
768 group is appended. (POSIX 1003.1e draft standard 17 allows to
769 add fields to ACL entries.)
770 If the user name or group name field is numeric because the
772 related user has no entry in the passwd/group database at the
773 time the archive is created, the additional numeric field may be
774 omitted.
775 This is an example of the format used for SCHILY.acl.access (a
777 space has been inserted after the equal sign and lines are bro‐
778 ken [marked with '\' ] for readability, additional fields in
779 bold):
780 SCHILY.acl.access= user::rwx,user:lisa:r-x:502, \
782 group::r-x,group:toolies:rwx:102, \
783 mask::rwx,other::r--x
784 If and only if the user ID 502 and group ID 102 have no
786 passwd/group entry, our example acl entry looks this way:
787 SCHILY.acl.access= user::rwx,user:502:r-x, \
789 group::r-x,group:102:rwx:, \
790 mask::rwx,other::r--x
791 The added numerical user and group identifiers are essential
793 when restoring a system completely from a backup, as initially
794 the name-to-identifier mappings may not be available, and then
795 file ownership restoration would not work.
796 When the archive is unpacked and the ACL entries for the files
798 are restored, first the additional numeric fields are removed
799 and an attempt is made to restore the resulting ACL data. If
800 that fails, the numeric fields are extracted and the related
801 user name and group name fields are replaced by the numeric
802 fields, before the ACL restore is retried.
803 As the archive format that is used for backing up access control
805 lists is compatible with the pax archive format, archives cre‐
806 ated that way can be restored by star or a POSIX.1-2001 compli‐
807 ant pax. Note that programs other than star will ignore the ACL
808 information.
809 SCHILY.acl.default
811 The default ACL for a file. See SCHILY.acl.access for more
812 information.
813 This is an example of the format used for SCHILY.acl.default (a
815 space has been inserted after the equal sign and lines are bro‐
816 ken [marked with '\' ] for readability, additional fields in
817 bold):
818 SCHILY.acl.default= user::rwx,user:lisa:r-x:502, \
820 group::r-x,mask::r-x,other::r-x
821 SCHILY.acl.type
823 The ACL type used for coding access control lists.
824 The following ACL types are possible:
826 POSIX draft
828 ACLs as defined in the withdrawn POSIX 1003.1e draft
829 standard 17.
830 NFSv4 ACLs as used by NFSv4, NTFS and ZFS.
832 Note that the SCHILY.acl.type keyword is currently not generated
834 by star. Star however accepts this keyword if it appears in
835 extended tar headers. The ACL type is determined from the exis‐
836 tence of the keyword type that holds the ACL text.
837 SCHILY.ddev
839 The device ids for names used is the SCHILY.dir dump directory
840 list from st_dev of the file as decimal number. The SCHILY.ddev
841 keyword is followed by a space separated list of device id num‐
842 bers. Each corresponds exactly to a name in the list found in
843 SCHILY.dir. If a specific device id number is repeated, a comma
844 (,) without a following space may be use to denote that the cur‐
845 rent device id number is identical to the previous number. This
846 keyword is used in dump mode. This keyword is not yet imple‐
847 mented. It will be implemented in case that star will support
848 incremental dumps that span more than one filesystem.
849 The value is a signed int. An implementation should be able to
851 handle at least 64 bit values. Note that the value is signed
852 because POSIX does not specify more than the type should be an
853 int.
854 SCHILY.dev
856 The device id from st_dev of the file as decimal number. This
857 keyword is used in dump mode.
858 The value is a signed int. An implementation should be able to
860 handle at least 64 bit values. Note that the value is signed
861 because POSIX does not specify more than the type should be an
862 int.
863 SCHILY.devmajor
865 The device major number of the file (from st_rdev) if it is a
866 character or block special file. The argument is a decimal num‐
867 ber. This field is used if the device major of the file is
868 greater than 2097151 (octal 7777777).
869 The value is a signed int. An implementation should be able to
871 handle at least 64 bit values. Note that the value is signed
872 because POSIX does not specify more than the type should be an
873 int.
874 SCHILY.devminor
876 The device minor number of the file (from st_rdev) if it is a
877 character or block special file. The argument is a decimal num‐
878 ber. This field is used if the device minor of the file is
879 greater than 2097151 (octal 7777777).
880 The value is a signed int. An implementation should be able to
882 handle at least 64 bit values. Note that the value is signed
883 because POSIX does not specify more than the type should be an
884 int.
885 SCHILY.devminorbits
887 The number of minorbits used in the device id from st_dev as
888 decimal number.
889 The value is mainly needed for SunOS where the number of minor
891 bits in st_dev depends on whether a program is run in 32 or 64
892 bit mode. There is no support for platforms that do not have the
893 minor part of the device id in a contiguous set of bits (like
894 e.g. FreeBSD).
895 SCHILY.dino
897 The inode numbers for names used is the SCHILY.dir dump direc‐
898 tory list from st_ino of the file as decimal number. The
899 SCHILY.dino keyword is followed by a space separated list of
900 inode numbers. Each corresponds exactly to a name in the list
901 found in SCHILY.dir. This keyword is used in dump mode.
902 The values are unsigned int. An implementation should be able
904 to handle at least 64 bit unsigned values.
905 SCHILY.dir
907 A list of filenames (the content) for the current directory.
908 The names are coded in UTF-8. Each file name is prefixed by a
909 single character that is used as a flag. Each file name is lim‐
910 ited by a null character. The null character is directly fol‐
911 lowed by he flag character for the next file name in case the
912 list is not terminated by the current file name. The flag char‐
913 acter must not be a null character. By default, a ^A (octal
914 001) is used. The following flags are defined:
915 \000 This is the list terminator character - the second
917 null byte, see below.
918 \001 (^A) The default flag that is used in case the dump dir
920 features have not been active or in case that the file
921 type is unknown.
922 \002 (^B) The related file is a FIFO special (named pipe).
924 \003 (^C) The related file is a character special.
926 \004 (^D) Reserved, used e.g. by XENIX multiplexed character
928 special.
929 \005 (^E) The related file is a directory.
931 \006 (^F) Reserved, used e.g. by XENIX named file.
933 \007 (^G) The related file is a block special.
935 \010 (^H) Reserved, used e.g. by XENIX multiplexed block spe‐
937 cial.
938 \011 (^I) The related file is a regular file.
940 \012 (^J) The related file is a contiguous file.
942 \013 (^K) The related file is a symbolic link.
944 \014 (^L) Reserved, used e.g. by Solaris shadow inode.
946 \015 (^M) The related file is a socket.
948 \016 (^N) The related file is a Solaris DOOR.
950 \017 (^O) The related file is a BSD whiteout entry.
952 \020 (^P) Reserved, used e.g. by UNOS eventcount.
954 Y A non directory file that is in the current (incremen‐
956 tal) dump.
957 N A non directory file that is not in the current
959 (incremental) dump.
960 D A directory that is in the current (incremental) dump.
962 d A directory that is not in the current (incremental)
964 dump.
965 The list is terminated by two successive null bytes. The first
967 is the null byte for the last file name. The second null byte
968 is at the position where a flag character would be expected, it
969 acts ad a list terminator. The length tag for the SCHILY.dir
970 data includes both null bytes.
971 If a dump mode has been selected that writes compact complete
973 directory information to the beginning of the archive, the flag
974 character may contain values different from ^A. Star implemen‐
975 tations at least up to star-1.5.1 do not use the feature to tag
976 entries and use the default entry \001 (^A) for all files. Tar
977 implementations that like to read archives that use the
978 SCHILY.dir keyword, shall not rely on values other than \000
979 (^@) or \001 (^A).
980 In 2016, with star-1.5.3 the values from \002 to \020 have been
982 introduced as a result of a libfind update that uses struct
983 dirent member d_type where available.
984 This keyword is used in dump mode.
986 SCHILY.fflags
988 A textual version of the BSD or Linux extended file flags.
989 The following flags are defined by star, the bold names are the
991 names that are generated and the other names are accepted on
992 input as well:
993 arch set the archived flag (super-user only).
995 archived Alias for arch.
997 compressed set the compressed flag (Mac OS only).
999 ucompressed Alias for compressed.
1001 hidden Set the file is hidden flag.
1003 uhidden Alias for hidden.
1005 nodump set the nodump flag (owner or super-user).
1007 offline Set the file is offline flag.
1009 uoffline Alias for offline.
1011 opaque set the opaque flag (owner or super-user).
1013 rdonly Set the readonly flag.
1015 urdonly Alias for rdonly.
1017 readonly Alias for rdonly.
1019 reparse Set the reparse flag.
1021 ureparse Alias for reparse.
1023 sappnd set the system append-only flag (super-user
1025 only).
1026 sappend Alias for sappnd.
1028 schg set the system immutable flag (super-user only).
1030 schange Alias for schg.
1032 simmutable Alias for schg.
1034 sparse Set the sparse flag.
1036 usparse Alias for sparse.
1038 sunlnk set the system undeletable flag (super-user
1040 only).
1041 sunlink Alias for sunlnk.
1043 system Set the system flag.
1045 usystem Alias for system.
1047 uappnd set the user append-only flag (owner or super-
1049 user).
1050 uappend Alias for uappnd.
1052 uchg set the user immutable flag (owner or super-
1054 user).
1055 uchange Alias for uchg.
1057 uimmutable Alias for uchg.
1059 uunlnk set the user undeletable flag (owner or super-
1061 user).
1062 uunlink Alias for uunlnk.
1064 The following flags are only available on Linux:
1066 compress Set the Linux compress flag (owner or super-
1068 user).
1069 dirsync Set the Linux dirsync flag (owner or super-user)
1071 that causes synchronous writes for directories.
1072 journal-data Set the Linux journal data flag (super-user
1074 only).
1075 noatime Set the Linux no access time flag (owner or
1077 super-user).
1078 nocow Set the Linux no copy on write flag (owner or
1080 super-user).
1081 notail Set the Linux no tail merging flag (owner or
1083 super-user).
1084 projinherit Set the Linux project inherit flag (owner or
1086 super-user).
1087 secdel Set the Linux secure deletion (purge before
1089 delete) flag (owner or super-user).
1090 sync Set the Linux sync flag (owner or super-user).
1092 topdir Set the Linux top of directory hierarchies flag
1094 (owner or super-user).
1095 undel Set the Linux allow unrm flag (owner or super-
1097 user).
1098 SCHILY.filetype
1100 A textual version of the real file type of the file. The fol‐
1101 lowing names are used:
1102 unallocated An unknown file type that may be a
1104 result of a unlink(2) operation. This
1105 should never happen.
1106 regular A regular file.
1108 contiguous A contiguous file. On operating systems
1110 or file systems that don't support this
1111 file type, it is handled like a regular
1112 file.
1113 symlink A symbolic link to any file type.
1115 directory A directory.
1117 character special A character special file.
1119 block special A block special file.
1121 fifo A named pipe.
1123 socket A UNIX domain socket.
1125 mpx character special A multiplexed character special file.
1127 mpx block special A multiplexed block special file.
1129 XENIX nsem A XENIX named semaphore.
1131 XENIX nshd XENIX shared data.
1133 door A Solaris door.
1135 eventcount A UNOS event count.
1137 whiteout A BSD whiteout directory entry.
1139 sparse A sparse regular file.
1141 volheader A volume header.
1143 unknown/bad Any other unknown file type. This
1145 should never happen.
1146 SCHILY.ino
1149 The inode number from st_ino of the file as decimal number.
1150 This keyword is used in dump mode.
1151 The value is an unsigned int. An implementation should be able
1153 to handle at least 64 bit unsigned values.
1154 SCHILY.nlink
1156 The link count of the file as decimal number. This keyword is
1157 used in dump mode.
1158 The value is an unsigned int. An implementation should be able
1160 to handle at least 32 bit unsigned values.
1161 SCHILY.offset
1163 The offset value for a multi volume continuation header. This
1164 keyword is used with multi volume continuation headers. Multi
1165 volume continuation headers are used to allow to start reading a
1166 multi volume archive past the first volume.
1167 SCHILY.offset specifies the byte offset within a file that was
1169 split across volumes as a result of a multi volume media change
1170 operation.
1171 The value is an unsigned int. An implementation should be able
1173 to handle at least 64 bit unsigned values.
1174 SCHILY.realsize
1176 The real size of the file as decimal number. This keyword is
1177 used if the real size of the file differs from the visible size
1178 of the file in the archive. The real file size differs from the
1179 size in the archive if the file type is sparse or if the file is
1180 a continuation file on a multi volume archive. In case the
1181 SCHILY.realsize keyword is needed, it must be past any size key‐
1182 word in case a size keyword is also present.
1183 As sparse files allocate less space on tape than a regular file
1185 and as a continued file that started on a previous volume only
1186 holds parts of the file, the SCHILY.realsize keyword holds a
1187 bigger number than the size keyword.
1188 The value is an unsigned int. An implementation should be able
1190 to handle at least 64 bit unsigned values.
1191 SCHILY.tarfiletype
1193 The following additional file types are used in SCHILY.tarfile‐
1194 type:
1195 hardlink
1197 A hard link to any file type.
1198 dumpdir
1200 A directory with dump entries
1201 multivol continuation
1203 A multi volume continuation for any file type.
1204 meta A meta entry (inode meta data only) for any file type.
1206 SCHILY.xattr.attr
1208 A POSIX.1-2001 coded version of the Linux extended file
1209 attributes. Linux extended file attributes are name/value
1210 pairs. Every attribute name results in a SCHILY.xattr.name tag
1211 and the value of the extended attribute is used as the value of
1212 the POSIX.1-2001 header tag. Note that this way of coding is
1213 not portable across platforms, even though it is compatible with
1214 the implementation on Mac OS X. A version for BSD may be cre‐
1215 ated but NFSv4 includes far more features with extended
1216 attribute files than Linux does.
1217 A future version of star will implement a similar method as the
1219 tar program on Solaris currently uses. When this implementation
1220 is ready, the SCHILY.xattr.name feature may be removed in favor
1221 of a truly portable implementation that supports Solaris also.
1222
1225 The following star vendor unique extensions may only appear in 'g'lobal
1226 extended pax headers:
1227 SCHILY.archtype
1229 The textual version of the archive type used. The textual val‐
1230 ues used for SCHILY.archtype are the same names that are used in
1231 the star command line options to set up a specific archive type.
1232 The following values may currently appear in a global extended
1234 header:
1235 xustar 'xstar' format without "tar" signature at header
1237 offset 508.
1238 exustar 'xustar' format variant that always includes x-
1240 headers and g-headers.
1241 A complete tar implementation must be prepared to handle all ar‐
1243 chives names as documented in star(1).
1244 In order to allow archive type recognition from this keyword,
1246 the minimum tape block size must be 2x512 bytes (1024 bytes) and
1247 the SCHILY.archtype keyword needs to be in the first 512 bytes
1248 of the content of the first 'g'lobal pax header. Then the first
1249 tape block may be scanned to recognize the archive type.
1250 SCHILY.release
1252 The textual version of the star version string and the platform
1253 name where this star has been compiled. The same text appears
1254 when calling star -version.
1255 Other implementations may use a version string that does not
1257 start with the text star.
1258 SCHILY.volhdr.blockoff
1260 This keyword is used for multi volume archives. It represents
1261 the offset within the whole archive expressed in 512 byte units.
1262 The value is an unsigned int with a valid range between 1 and
1264 infinity. An implementation should be able to handle at least 64
1265 bit unsigned values.
1266 SCHILY.volhdr.blocksize
1268 The tape blocksize expressed in 512 byte units that was used
1269 when writing the archive.
1270 The value is an unsigned int with a valid range between 1 and
1272 infinity. An implementation should be able to handle at least 31
1273 bit unsigned values.
1274 SCHILY.volhdr.cwd
1276 This keyword is used in dump mode. It is only emitted in case
1277 the fs-name= option of star was used to overwrite the
1278 SCHILY.volhdr.filesys value. If SCHILY.volhdr.cwd is present,
1279 it contains the real backup working directory.
1280 Overwriting SCHILY.volhdr.filesys is needed when backups are run
1282 on file system snapshots rather than on the real file system.
1283 SCHILY.volhdr.device
1285 This keyword is used in dump mode. It represents the name of
1286 the device that holds the file system data. For disk based file
1287 systems, this is the device name of the mounted device.
1288 This keyword is optional. It helps to correctly identify the
1290 file system from which this dump has been made.
1291 SCHILY.volhdr.dumpdate
1293 This keyword is used in dump mode. It represents the time the
1294 current dump did start.
1295 SCHILY.volhdr.dumplevel
1297 This keyword is used in dump mode. It represents the level of
1298 the current dump. Dump levels are small numbers, the lowest
1299 possible number is 0. Dump level 0 represents a full backup.
1300 Dump level 1 represents a backup that contains all changes that
1301 did occur since the last level 0 dump. Dump level 2 represents
1302 a backup that contains all changes that did occur since the last
1303 level 1 dump. Star does not specify a maximum allowed dump
1304 level but you should try to keep the numbers less than 100.
1305 The value is an unsigned int with a valid range between 0 and at
1307 least 100.
1308 SCHILY.volhdr.dumptype
1310 This keyword is used in dump mode. If the dump is a complete
1311 dump of a file system (i.e. no files are excluded via command
1312 line), then the argument is the text full, else the argument is
1313 the text partial.
1314 SCHILY.volhdr.filesys
1316 This keyword is used in dump mode. It represents the top level
1317 directory for the file system from which this dump has been
1318 made. If the dump represents a dump that has an associated
1319 level, then the this directory needs to be identical to the root
1320 directory of this file system which is the mount point.
1321 SCHILY.volhdr.hostname
1323 This keyword is used in dump mode. The value is retrieved from
1324 gethostname(3) or uname(2).
1325 SCHILY.volhdr.label
1327 The textual volume label. The volume label must be identical
1328 within a set of multi volume archives.
1329 SCHILY.volhdr.refdate
1331 This keyword is used in dump mode if the current dump is an
1332 incremental dump with a level > 0. It represents the time the
1333 related dump did start.
1334 SCHILY.volhdr.reflevel
1336 This keyword is used in dump mode if the current dump is an
1337 incremental dump with a level > 0. It represents the level of
1338 the related dump. The related dump is the last dump with a
1339 level that is lower that the level of this dump. If a dump with
1340 the level of the current dump -1 exists, then this is the
1341 related dump level. Otherwise, the dump level is decremented
1342 until a valid dump level could be found in the dump database.
1343 The value is an unsigned int with a valid range between 0 and at
1345 least 100.
1346 SCHILY.volhdr.tapesize
1348 This keyword is used for multi volume archives and may be used
1349 to verify the volume size on read back. It represents the tape
1350 size expressed in 512 byte units. This keyword is set in multi
1351 volume mode if the size of the tape was not autodetected but set
1352 from a command line option.
1353 The value is an unsigned int with a valid range between 1 and
1355 infinity. An implementation should be able to handle at least 64
1356 bit unsigned values.
1357 SCHILY.volhdr.volume
1359 This keyword is used for multi volume archives. It represents
1360 the volume number within a volume set. The number used for the
1361 first volume is 1.
1362 The value is an unsigned int with a valid range between 1 and
1364 infinity. An implementation should be able to handle at least 31
1365 bit unsigned values.
1366
1368 Multi volume archives always use volume headers. Starting with the sec‐
1369 ond volume, there is a multi volume header that helps to skip the rest
1370 of the file that was split at the end of the previous volume.
1371 Star is able to work with arbitrary unknown volume sizes by detecting
1373 the end of the current media via a write() call that returns 0. A
1374 fixed media size is used, when the option tsize=# has been specified.
1375 Since star uses a fifo for optimizing the I/O, except when called with
1377 the option -no-fifo, it is not possible to know the name of the file
1378 that is split at a volume limit nor to know the offset in that file.
1379 Unless POSIX.1-2001 extensions are used, star does not verify whether a
1380 follow up volume is the right follow up volume. For this reason, it is
1381 recommended to create multi volume archives only with archive formats
1382 that support POSIX.1-2001 extensions.
1383 The following POSIX.1-2001 extensions are used together with multi vol‐
1385 ume archives:
1386 SCHILY.volhdr.label
1388 the volume lavel is used to help to identify a set of volumes.
1389 SCHILY.volhdr.dumpdate
1391 The start of the dump with nanosecond precision is used to iden‐
1392 tify the correct follow up volume.
1393 SCHILY.volhdr.volno
1395 The volume number counts starting with 1 and is used to identify
1396 the correct follow up volume.
1397 SCHILY.volhdr.blockoff
1399 The number of blocks read with all previous volumes.
1400 SCHILY.volhdr.tapesize
1402 The tape size in case that the tsize=# option was used.
1403
1406 spax(1), suntar(1), scpio(1), tar(1), cpio(1), pax(1), star_sym(1),
1407 tartest(1), star(1)
1408
1412 A tar command appeared in Seventh Edition Unix, which was released in
1413 January, 1979. It replaced the tp program from Fourth Edition Unix
1414 which replaced the tap program from First Edition Unix.
1415 Star was first created in 1982 to extract tapes on a UNIX clone (UNOS)
1417 that had no tar command. In 1985 the first fully functional version
1418 has been released as mtar.
1419 When the old star format extensions have been introduced in 1985, it
1421 was renamed to star (Schily tar). In 1994, Posix 1003.1-1988 exten‐
1422 sions were added and star was renamed to star (Standard tar).
1423
1426 Joerg Schilling
1427 Seestr. 110
1428 D-13353 Berlin
1429 Germany
1430 Mail bugs and suggestions to:
1432 joerg.schilling@fokus.fraunhofer.de or joerg@schily.net
1434Joerg Schilling 2019/03/19 STAR(4L)