[
https://issues.apache.org/jira/browse/COMPRESS-398?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16027756#comment-16027756
]
Stefan Bodewig commented on COMPRESS-398:
-----------------------------------------
Unfortunately the GNU tar page contradicts other sources, see
https://www.freebsd.org/cgi/man.cgi?query=tar&sektion=5&manpath=FreeBSD+8-current
for example.
under "Old style archive format"
{quote}
the mode, uid, and gid fields must end in a space and a
null byte; the size and mtime fields must end in a space; the checksum is
terminated by a null and a space. Early implementations filled the
numeric fields with leading spaces. This seems to have been common prac-
tice until the IEEE Std 1003.1-1988 (``POSIX.1'') standard was released.
{quote}
under "POSIX ustar Archives"
{quote}
POSIX requires numeric fields to be zero-padded in
the front, and requires them to be terminated with either space or NUL
characters.
{quote}
There are lots of dialects and we have special case codes for most of them.
There are dialects that use binary values inside the size fields in order to
represent sizes bigger than 8GiB for example. Any application that tries to
read tar archives is bound to replicate the same set of heuristics in order to
adapt to the multitude of dialects.
Commons Compress by default uses the "old ustar" format as it is understood by
most applications trying to read a tar and here a terminating SPACE has been
the most common option.
> Uncorrect string terminal symbol in entry when creating Tar archive using
> TarArchiveOutputStream
> ------------------------------------------------------------------------------------------------
>
> Key: COMPRESS-398
> URL: https://issues.apache.org/jira/browse/COMPRESS-398
> Project: Commons Compress
> Issue Type: Bug
> Components: Archivers
> Affects Versions: 1.14
> Reporter: Yaroslav Trymbach
> Priority: Minor
>
> I create Tar archive using TarArchiveOutputStream. And I've got one
> contradiction in output achive file with Tar-file format specification.
> https://www.gnu.org/software/tar/manual/html_node/Standard.html#SEC186
> Specification has next sentention for entry header fields:
> "The name, linkname, magic, uname, and gname are null-terminated character
> strings. All other fields are zero-filled octal numbers in ASCII. Each
> numeric field of width w contains w minus 1 digits, and a null."
> But in file generated TarArchiveOutputStream octal numbers fields (mode,
> size, checksum etc) has terminated character not NULL (0x00) but SPACE
> (0x20), so some programs have problems while work with this files.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
