bsdttar from the
  libarchive project, and commercial Unixes will have their own
  versions.  Known problems arise from
  
- The handling of file paths of more than 100 bytes.  These were
    unsupported in early versions oftar, and supported in one
    way by POSIXtarand in another by GNUtarand
    yet another by the POSIXpaxcommand which
    recenttarprograms often support.  The internal
    implementation warns on paths of more than 100 bytes,
    uses theustarway from the 1998 POSIX
    standard which supports up to 256 bytes (depending on the path: in
    particular the final component is limited to 100 bytes) if possible,
    otherwise the GNU way (which is widely supported, including byuntar).
    Most formats do not record the encoding of file paths.
(File) links.tarwas developed on an OS that used
    hard links, and physical files that were referred to more than once
    in the list of files to be included were included only once, the
    remaining instances being added as links.  Later a means to include
    symbolic links was added.  The internal implementation supports
    symbolic links (on OSes that support them), only.  Of course, the
    question arises as to how links should be unpacked on OSes that do
    not support them: for regular files file copies can be used.    Names of links in theustarformat are restricted to 100
    bytes.  There is an GNU extension for arbitrarily long link names,
    butbsdtarignores it.  The internal method uses the
    GNU extension, with a warning.Header fields, in particular the padding to be used when
    fields are not full or not used.  POSIX did define the correct
    behaviour but commonly used implementations did (and still do)
    not comply.File sizes.  Theustarformat is restricted to 8GB
    per (uncompressed) file.
  For portability, avoid file paths of more than 100 bytes and all links
  (especially hard links and symbolic links to directories).
  The internal implementation writes only the blocks of 512 bytes
  required (including trailing blocks of nuls), unlike GNU tar
  which by default pads with nul to a multiple of 20 blocks
  (10KB).  Implementations which pad differ on whether the block padding
  should occur before or after compression (or both): padding was
  designed for improved performance on physical tape drives.