#1371 ustar extended header meta-data is not properly decoded

open
None
5
2013-08-23
2013-08-23
No

The SunOS 5.10 version of tar writes "ustar" archives. http://en.wikipedia.org/wiki/Tar_(computing)#UStar_format

These archives have a 100 characters file name limit. It is possible to bypass this limit by using the "E" flag to generate an extended header (POSIX.1-2001). See Type Flag Field table in above link. When the "E" flag is used and the file name is > 100 characters it appears that tar will write a place holder in the tar header filename field (which appears to be an integer of some sort, perhaps an index) and puts the file name in the extended header.

7-Zip (9.20) is not identifying/parsing this extended header it is treating them as separate files in-and-of themselves. When I open one of these tar archives I see 2 things.
1. The file name listed in the Pre-POSIX.1-1988 tar header (bytes 0-99).
2. A subdirectory with the meta data listed as files.

GNU tar is able to properly extract these tar archives and does not exhibit the above 2 symptoms. [tar (GNU tar) 1.26, Packaged by Cygwin (1.26-1)]

I am attaching a sample file (test-tar.tar) that demonstrates the problem. It was created on a SunOS 5.10 system using tar VERSION: 11.10.0,REV=2005.01.21.15.53.

Sun tar "E" flag details:
Write a tarfile with extended headers. (Used with c, r, or u function letters. Ignored with t or x function letters.) When a tarfile is written with extended headers, the modifi- cation time is maintained with a granularity of microseconds rather than seconds. In addi- tion, filenames no longer than PATH_MAX char- acters that could not be archived without E, and file sizes greater than 8GB, are sup- ported. The E flag is required whenever the larger files and/or files with longer names, or whose UID/GID exceed 2097151, are to be archived, or if time granularity of microseconds is desired.

1 Attachments

Discussion


Log in to post a comment.