Re: [Bug-tar] GNU tar 1.22 creating USTAR not readable by other TAR implementations

[Tim Kientzle]

I've done a lot of reading of the POSIX.1 specification
for ustar format and think I can answer most of your questions.

Two references you might find useful:

* The official specification for ustar format:
http://www.opengroup.org/onlinepubs/009695399/utilities/pax.html

* I compiled a lot of information about tar variants and
extensions for FreeBSD's tar.5 man page:
http://code.google.com/p/libarchive/wiki/ManPageTar5

Kent Boortz wrote:
> This is how I interpret the USTAR format, but could be wrong of course
>
>   - We have 155 characters in the "prefix" field
>   - We have 100 characters in the "name" field
>   - The strings in "prefix" and "name" can fill the fields, but
>     if the string is shorter than the limit, it is null terminated

These are all exactly correct.  In particular, the name
and prefix are allowed to fill their fields, in which case
they would be unterminated.

>   - The field "name" can't be empty (is this stated in the standard?)

I don't recall this being officially required,
though I've always treated it as such.  I
expect many implementations do require this.

>   - We split on dir/dir or dir/file boundaries (is this stated in the
>     standard?)

This is required by the standard.  The separating '/' is
not stored; the reader is required to insert a new '/' when
the fields are assembled.  (In particular, note that if you
do leave the filename portion blank, you can only do so
for a directory, because the inserted '/' will be a trailing
'/' in that case.)

>   - If path ends in a directory, "name" ends with a slash (is this
>     stated in standard?)

This is not required in the standard.  As far as I've
been able to tell, this was part of the very earliest
implementations and has been widely retained.  I've
personally considered it "highly recommended"; that is,
I would omit the trailing slash if it allowed a directory
to be stored whose name would otherwise not fit (possibly
with a warning) but would otherwise include it.

Cheers,

Tim