Tim Kientzle <[email protected]> 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
