[Sunhelp] SunOS 4.1.3 & long file names & tar

[James Lockwood]

On Fri, 19 Nov 1999, Gregory Leblanc wrote: 

> Can somebody explain how it "breaks" the "standard"?  I just tried to untar
> the sgmltools source on Solaris7 and it didn't work, but when I used the
> gnu-tar that I just compiled it worked fine.  I'd sort of like to see what I

(from README.otherbugs included with the star distribution)

4)      gnutar
Claims not to be conforming to Posix 1003.1. (gnu is not tar)

- Many bugs in implementation and design.
  (e.g. when handling/creating multi volume archives)
- The second logical EOF block in GNU-tar archives is missing
  with a 50% chance.
  This will cause correctly working tar implementations to complain
  about an illegal/missing EOF in the tar archive.
- Deeply nested directory trees will not be dumped:
  Error message is: Too many open files
  (This is a similar implementation bug as found in Solaris tar
   with the /dev/fd loop)
- Hard links with long names to files with long names do not work.

- GNU-tar cannot read Posix compliant tar archives with
  long file names if the filename prefix it at least 138 characters.
  GNU-tar will think that it found an extended sparse GNU tar archive
  and get out of sync for the rest of the archive.
  See --sparse design bug description below.

- Option --sparse produces archives which cannot be read by any
  other tar implementation known to me (except star), because
  they will get "out of sync".
  Posix 1003.1 conforming tar archives let gnutar get "out of sync"
  even if the --portability option is used (see above).
  This is a severe design bug in GNU-tar.

        Description:
        The size field in a tar archive cannot reflect the
        real size of a sparse file to have compatibility to
        other implementations (this is also true for "star" archives).

        If the "sparse" file contains more than 4 holes,
        the "size" field in the GNU-tar control block does not
        reflect the total size of the (shrunk) sparse file in the archive
        because it does not count the 'sparse' extension headers.
        Posix conformant archives that use the name prefix field with more than
        137 characters will have a value != 0 on a field that
        that makes gnutar believe that such an extension
        header is present - GNU-tar will get out of sync.

        Note: The general rule for any tar is that it should
        be able to read any "tar" compliant data stream with
        the exception that enhancements to the standard
        only will fail on the files that contain the extension.
        Those files should be extracted as if they were
        regular files.

Note: I do not recommend GNU tar as an exchange format.
      Use star -Hustar for maximum portability instead.

-James