1STAR(4L)                    Schily´s USER COMMANDS                    STAR(4L)
2
3
4

NAME

6       star - tape archive file format
7

DESCRIPTION

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

BASIC TAR STRUCTURE

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
22       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
27       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
33       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
36       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
41

BASIC TAR HEADER DESCRIPTION

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
51       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
59       #define   TMODLEN        8
60       #define   TUIDLEN        8
61       #define   TGIDLEN        8
62       #define   TSIZLEN        12
63       #define   TMTMLEN        12
64       #define   TCKSLEN        8
65
66       #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
74       /*
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
87       /*
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
97       See section EXTENDED TAR (PAX) HEADER  KEYWORDS  for  more  information
98       about the structure of a POSIX.1-2001 header.
99
100       /*
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
108       #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
120       /*
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
136       #define   TALLMODES 07777     /* The low 12 bits       */
137
138       /*
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
162       /*
163        * star header specific definitions
164        */
165       #define   STMAGIC        "tar"     /* star magic */
166       #define   STMAGLEN       4         /* "tar" including '\0' */
167
168       /*
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
209       struct sparse {
210            char t_offset[12];
211            char t_numbytes[12];
212       };
213
214       #define   SPARSE_EXT_HDR  21
215
216       struct xstar_ext_header {
217            struct sparse t_sp[21];
218            char t_isextended;
219       };
220
221       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
229       For  maximum  portability,  all  fields  that contain character strings
230       should be limited to use the low 7 bits of a character.
231
232       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
237       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
245       The  fields  magic,  uname  and gname contain null terminated character
246       strings.
247
248       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
252       The typeflag field contains a single character.
253
254       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
264       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
275       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
281       The rightmost character in a 8 or 12 character field contains the least
282       significant base 256 number.
283
284       Recent GNU tar and BSD libarchive versions implement  the  same  exten‐
285       sion.
286
287       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
291       The  mode field contains 12 bits holding permissions, see above for the
292       definitions for each of the permission bits.
293
294       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
297       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
302       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
310       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
316       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
324       '0' REGTYPE
325              A regular file.  If the size field is non zero, then  file  data
326              follows the header.
327
328       '\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
334       '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
344       '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
350       '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
356       '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
362       '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
373       '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
378       '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
384       '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
393       '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
402       'A' - 'Z'
403              Reserved for vendor specific implementations.
404
405       '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
412       '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
417       '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
422       '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
429       '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
437       '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
444       '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
458       'N'    An outdated linktype used by old GNU tar versions to store  long
459              file names.  This type is unsupported by star.
460
461       '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
477       '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
483       '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
490       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

EXTENDED TAR (PAX) HEADER STRUCTURE

496       Block type                            Description
497
498       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
509

EXTENDED TAR (PAX) HEADER FORMAT

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
514              "%d %s=%s\n", <length>, <keyword>, <value>
515
516       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
520       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
524       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
528       Null characters do not delimit any value. The data used  for  value  is
529       only limited by its implicit length.
530

EXTENDED TAR (PAX) HEADER KEYWORDS

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
537       atime  The time from st_atime in sub  second  granularity.   Star  cur‐
538              rently supports a nanosecond granularity.
539
540       charset
541              The  name  of  the  character set used to encode the data in the
542              following file(s).
543
544              The following values are supported for charset:
545
546              ISO-IR 646 1990          ISO/IEC 646:1990
547
548              ISO-IR 8859 1 1998       ISO/IEC 8859-1:1998
549
550              ISO-IR 8859 2 1998       ISO/IEC 8859-2:1998
551
552              ISO-IR 8859 3 1998       ISO/IEC 8859-3:1998
553
554              ISO-IR 8859 4 1998       ISO/IEC 8859-4:1998
555
556              ISO-IR 8859 5 1998       ISO/IEC 8859-5:1998
557
558              ISO-IR 8859 6 1998       ISO/IEC 8859-6:1998
559
560              ISO-IR 8859 7 1998       ISO/IEC 8859-7:1998
561
562              ISO-IR 8859 8 1998       ISO/IEC 8859-8:1998
563
564              ISO-IR 8859 9 1998       ISO/IEC 8859-9:1998
565
566              ISO-IR 8859 10 1998      ISO/IEC 8859-10:1998
567
568              ISO-IR 8859 11 1998      ISO/IEC 8859-11:1998
569
570              ISO-IR 8859 12 1998      ISO/IEC 8859-12:1998
571
572              ISO-IR 8859 13 1998      ISO/IEC 8859-13:1998
573
574              ISO-IR 8859 14 1998      ISO/IEC 8859-14:1998
575
576              ISO-IR 8859 15 1998      ISO/IEC 8859-15:1998
577
578              ISO-IR 10646 2000        ISO/IEC 10646:2000
579
580              ISO-IR 10646 2000 UTF-8  ISO/IEC 10646, UTF-8 encoding
581
582              BINARY                   None
583
584              This keyword is currently ignored by star.
585
586       comment
587              Any number of characters that  should  be  treated  as  comment.
588              Star ignores the comment as documented by the POSIX standard.
589
590       ctime  The  time  from  st_ctime  in sub second granularity.  Star cur‐
591              rently supports a nanosecond granularity.
592
593       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
597       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
602       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
609              The following values are supported for hdrcharset:
610
611              ISO-IR 10646 2000 UTF-8  ISO/IEC 10646, UTF-8 encoding
612
613              BINARY                   None
614
615              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
619       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
625       mtime  The time from st_mtime in sub  second  granularity.   Star  cur‐
626              rently supports a nanosecond granularity.
627
628       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
633       realtime.any
634              The keywords prefixed by  realtime.   are  reserved  for  future
635              standardization.
636
637       security.any
638              The  keywords  prefixed  by  security.   are reserved for future
639              standardization.
640
641       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
647       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
651       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
656       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

SCHILY PAX EXTENSION KEYWORDS

663       Star uses own vendor specific extensions. The  SCHILY  vendor  specific
664       extended pax header keywords are:
665
666       SCHILY.acl.ace
667              The NFSv4 ACL for a file.
668
669              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
673              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
677              acl_totext(aclp, \
678                  ACL_COMPACT_FMT | ACL_APPEND_ID | ACL_SID_FMT);
679
680              The flags have the following meaning:
681
682              ACL_COMPACT_FMT
683                     Create  the  compact  version of the ACL text representa‐
684                     tion.
685
686              ACL_APPEND_ID
687                     Append uid or gid for additional user or group entries.
688
689              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
694              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
698              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
707              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
712              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
717              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
726              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
731              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
735              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
741              acl_totext(aclp, ACL_APPEND_ID | ACL_SID_FMT);
742
743
744              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
750
751       SCHILY.acl.access
752              The withdrawn POSIX draft ACL for a file.
753
754              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
761              Note that the POSIX 1003.1e draft has been withdrawn in 1997 but
762              some operating systems still support it with some filesystems.
763
764              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
771              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
776              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
781              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
785              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
788              SCHILY.acl.access= user::rwx,user:502:r-x, \
789                                 group::r-x,group:102:rwx:, \
790                                 mask::rwx,other::r--x
791
792              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
797              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
804              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
810       SCHILY.acl.default
811              The  default  ACL  for  a  file.  See SCHILY.acl.access for more
812              information.
813
814              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
819              SCHILY.acl.default= user::rwx,user:lisa:r-x:502, \
820                                  group::r-x,mask::r-x,other::r-x
821
822       SCHILY.acl.type
823              The ACL type used for coding access control lists.
824
825              The following ACL types are possible:
826
827              POSIX draft
828                     ACLs  as  defined  in  the  withdrawn POSIX 1003.1e draft
829                     standard 17.
830
831              NFSv4  ACLs as used by NFSv4, NTFS and ZFS.
832
833              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
838       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
850              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
855       SCHILY.dev
856              The  device  id from st_dev of the file as decimal number.  This
857              keyword is used in dump mode.
858
859              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
864       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
870              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
875       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
881              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
886       SCHILY.devminorbits
887              The  number  of  minorbits  used in the device id from st_dev as
888              decimal number.
889
890              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
896       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
903              The values are unsigned int.  An implementation should  be  able
904              to handle at least 64 bit unsigned values.
905
906       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
916              \000      This is the list terminator  character  -  the  second
917                        null byte, see below.
918
919              \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
923              \002 (^B) The related file is a FIFO special (named pipe).
924
925              \003 (^C) The related file is a character special.
926
927              \004 (^D) Reserved,  used  e.g.  by  XENIX multiplexed character
928                        special.
929
930              \005 (^E) The related file is a directory.
931
932              \006 (^F) Reserved, used e.g. by XENIX named file.
933
934              \007 (^G) The related file is a block special.
935
936              \010 (^H) Reserved, used e.g. by XENIX  multiplexed  block  spe‐
937                        cial.
938
939              \011 (^I) The related file is a regular file.
940
941              \012 (^J) The related file is a contiguous file.
942
943              \013 (^K) The related file is a symbolic link.
944
945              \014 (^L) Reserved, used e.g. by Solaris shadow inode.
946
947              \015 (^M) The related file is a socket.
948
949              \016 (^N) The related file is a Solaris DOOR.
950
951              \017 (^O) The related file is a BSD whiteout entry.
952
953              \020 (^P) Reserved, used e.g. by UNOS eventcount.
954
955              Y         A non directory file that is in the current (incremen‐
956                        tal) dump.
957
958              N         A non directory  file  that  is  not  in  the  current
959                        (incremental) dump.
960
961              D         A directory that is in the current (incremental) dump.
962
963              d         A  directory  that is not in the current (incremental)
964                        dump.
965
966              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
972              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
981              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
985              This keyword is used in dump mode.
986
987       SCHILY.fflags
988              A textual version of the BSD or Linux extended file flags.
989
990              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
994              arch           set the archived flag (super-user only).
995
996              archived       Alias for arch.
997
998              compressed     set the compressed flag (Mac OS only).
999
1000              ucompressed    Alias for compressed.
1001
1002              hidden         Set the file is hidden flag.
1003
1004              uhidden        Alias for hidden.
1005
1006              nodump         set the nodump flag (owner or super-user).
1007
1008              offline        Set the file is offline flag.
1009
1010              uoffline       Alias for offline.
1011
1012              opaque         set the opaque flag (owner or super-user).
1013
1014              rdonly         Set the readonly flag.
1015
1016              urdonly        Alias for rdonly.
1017
1018              readonly       Alias for rdonly.
1019
1020              reparse        Set the reparse flag.
1021
1022              ureparse       Alias for reparse.
1023
1024              sappnd         set   the  system  append-only  flag  (super-user
1025                             only).
1026
1027              sappend        Alias for sappnd.
1028
1029              schg           set the system immutable flag (super-user only).
1030
1031              schange        Alias for schg.
1032
1033              simmutable     Alias for schg.
1034
1035              sparse         Set the sparse flag.
1036
1037              usparse        Alias for sparse.
1038
1039              sunlnk         set  the  system  undeletable  flag   (super-user
1040                             only).
1041
1042              sunlink        Alias for sunlnk.
1043
1044              system         Set the system flag.
1045
1046              usystem        Alias for system.
1047
1048              uappnd         set  the  user  append-only flag (owner or super-
1049                             user).
1050
1051              uappend        Alias for uappnd.
1052
1053              uchg           set the user  immutable  flag  (owner  or  super-
1054                             user).
1055
1056              uchange        Alias for uchg.
1057
1058              uimmutable     Alias for uchg.
1059
1060              uunlnk         set  the  user  undeletable flag (owner or super-
1061                             user).
1062
1063              uunlink        Alias for uunlnk.
1064
1065              The following flags are only available on Linux:
1066
1067              compress       Set the Linux  compress  flag  (owner  or  super-
1068                             user).
1069
1070              dirsync        Set  the Linux dirsync flag (owner or super-user)
1071                             that causes synchronous writes for directories.
1072
1073              journal-data   Set  the  Linux  journal  data  flag  (super-user
1074                             only).
1075
1076              noatime        Set  the  Linux  no  access  time  flag (owner or
1077                             super-user).
1078
1079              nocow          Set the Linux no copy on  write  flag  (owner  or
1080                             super-user).
1081
1082              notail         Set  the  Linux  no  tail  merging flag (owner or
1083                             super-user).
1084
1085              projinherit    Set the Linux  project  inherit  flag  (owner  or
1086                             super-user).
1087
1088              secdel         Set  the  Linux  secure  deletion  (purge  before
1089                             delete) flag (owner or super-user).
1090
1091              sync           Set the Linux sync flag (owner or super-user).
1092
1093              topdir         Set the Linux top of directory  hierarchies  flag
1094                             (owner or super-user).
1095
1096              undel          Set  the  Linux  allow unrm flag (owner or super-
1097                             user).
1098
1099       SCHILY.filetype
1100              A textual version of the real file type of the file.   The  fol‐
1101              lowing names are used:
1102
1103              unallocated             An  unknown  file  type  that  may  be a
1104                                      result of a unlink(2)  operation.   This
1105                                      should never happen.
1106
1107              regular                 A regular file.
1108
1109              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
1114              symlink                 A symbolic link to any file type.
1115
1116              directory               A directory.
1117
1118              character special       A character special file.
1119
1120              block special           A block special file.
1121
1122              fifo                    A named pipe.
1123
1124              socket                  A UNIX domain socket.
1125
1126              mpx character special   A multiplexed character special file.
1127
1128              mpx block special       A multiplexed block special file.
1129
1130              XENIX nsem              A XENIX named semaphore.
1131
1132              XENIX nshd              XENIX shared data.
1133
1134              door                    A Solaris door.
1135
1136              eventcount              A UNOS event count.
1137
1138              whiteout                A BSD whiteout directory entry.
1139
1140              sparse                  A sparse regular file.
1141
1142              volheader               A volume header.
1143
1144              unknown/bad             Any  other  unknown  file  type.    This
1145                                      should never happen.
1146
1147
1148       SCHILY.ino
1149              The  inode  number  from  st_ino  of the file as decimal number.
1150              This keyword is used in dump mode.
1151
1152              The value is an unsigned int.  An implementation should be  able
1153              to handle at least 64 bit unsigned values.
1154
1155       SCHILY.nlink
1156              The  link  count of the file as decimal number.  This keyword is
1157              used in dump mode.
1158
1159              The value is an unsigned int.  An implementation should be  able
1160              to handle at least 32 bit unsigned values.
1161
1162       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
1168              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
1172              The value is an unsigned int.  An implementation should be  able
1173              to handle at least 64 bit unsigned values.
1174
1175       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
1184              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
1189              The value is an unsigned int.  An implementation should be  able
1190              to handle at least 64 bit unsigned values.
1191
1192       SCHILY.tarfiletype
1193              The  following additional file types are used in SCHILY.tarfile‐
1194              type:
1195
1196              hardlink
1197                     A hard link to any file type.
1198
1199              dumpdir
1200                     A directory with dump entries
1201
1202              multivol continuation
1203                     A multi volume continuation for any file type.
1204
1205              meta   A meta entry (inode meta data only) for any file type.
1206
1207       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
1218              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
1223

SCHILY 'G'LOBAL PAX EXTENSION KEYWORDS

1225       The following star vendor unique extensions may only appear in 'g'lobal
1226       extended pax headers:
1227
1228       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
1233              The following values may currently appear in a  global  extended
1234              header:
1235
1236              xustar         'xstar'  format without "tar" signature at header
1237                             offset 508.
1238
1239              exustar        'xustar' format variant that always  includes  x-
1240                             headers and g-headers.
1241
1242              A complete tar implementation must be prepared to handle all ar‐
1243              chives names as documented in star(1).
1244
1245              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
1251       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
1256              Other implementations may use a version  string  that  does  not
1257              start with the text star.
1258
1259       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
1263              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
1267       SCHILY.volhdr.blocksize
1268              The tape blocksize expressed in 512 byte  units  that  was  used
1269              when writing the archive.
1270
1271              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
1275       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
1281              Overwriting SCHILY.volhdr.filesys is needed when backups are run
1282              on file system snapshots rather than on the real file system.
1283
1284       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
1289              This  keyword  is  optional.  It helps to correctly identify the
1290              file system from which this dump has been made.
1291
1292       SCHILY.volhdr.dumpdate
1293              This keyword is used in dump mode.  It represents the  time  the
1294              current dump did start.
1295
1296       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
1306              The value is an unsigned int with a valid range between 0 and at
1307              least 100.
1308
1309       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
1315       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
1322       SCHILY.volhdr.hostname
1323              This keyword is used in dump mode.  The value is retrieved  from
1324              gethostname(3) or uname(2).
1325
1326       SCHILY.volhdr.label
1327              The  textual  volume  label.  The volume label must be identical
1328              within a set of multi volume archives.
1329
1330       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
1335       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
1344              The value is an unsigned int with a valid range between 0 and at
1345              least 100.
1346
1347       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
1354              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
1358       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
1363              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

MULTI VOLUME ARCHIVE HANDLING

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
1372       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
1376       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
1384       The following POSIX.1-2001 extensions are used together with multi vol‐
1385       ume archives:
1386
1387       SCHILY.volhdr.label
1388              the volume lavel is used to help to identify a set of volumes.
1389
1390       SCHILY.volhdr.dumpdate
1391              The start of the dump with nanosecond precision is used to iden‐
1392              tify the correct follow up volume.
1393
1394       SCHILY.volhdr.volno
1395              The volume number counts starting with 1 and is used to identify
1396              the correct follow up volume.
1397
1398       SCHILY.volhdr.blockoff
1399              The number of blocks read with all previous volumes.
1400
1401       SCHILY.volhdr.tapesize
1402              The tape size in case that the tsize=# option was used.
1403
1404

SEE ALSO

1406       spax(1), suntar(1), scpio(1),  tar(1),  cpio(1),  pax(1),  star_sym(1),
1407       tartest(1), star(1)
1408

NOTES

BUGS

HISTORY

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
1416       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
1420       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
1424

AUTHOR

1426       Joerg Schilling
1427       Seestr. 110
1428       D-13353 Berlin
1429       Germany
1430
1431       Mail bugs and suggestions to:
1432
1433       joerg.schilling@fokus.fraunhofer.de or joerg@schily.net
1434
1435
1436
1437
1438Joerg Schilling                   2019/03/19                          STAR(4L)
Impressum