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

[Kent Boortz]

Tim Kientzle <address@hidden> writes:
>> So with the restriction that the "name" field is not to be empty, no
>> component of the path can be more than 100 characters,...
>
> No, I'm afraid you're oversimplifying.
>
> The following file can be stored, even though
> it has a component of 155 characters:
>    ('a' x 155) + '/' + ('b' x 100)
>
> It's just the parent directory of that file
> that can't be stored.

Thanks for clarifying, was not aware it was hanled differently.

> In fact, I suggest you modify your test to
> explicitly archive just the one entry with the
> full path being tested, rather than the parent
> directory.  That would avoid some false error
> messages from the parent directories:

I did, and it seems with that kind of usage, giving the complete path,
GNU tar always (in my tests) produces a package that Solaris TAR can
read. I attached the test results and the updated script.

The result file now also lists results for CMake 2.8.0, but none of
the other TARs likes the way CMake packs, it just wildly throws away
part of the path, and returns 0 as if nothing happened ;)

Not shown in the result file, but I also tried a run on AIX 5.3 and
HP-UX 11.31. Their TAR implementations disliked the same TAR files
created by GNU tar as Solaris does, so seems like that avoiding an
empty "name" field when possible is what gives better "legacy"
compatibility,

kent

TARERR4.gz
Description: Binary data

ustartest
Description: Binary data

-- 
Kent Boortz, Senior Production Engineer
Sun Microsystems Inc., the MySQL team
Office: +46 863 11 363
Mobile: +46 70 279 11 71