[Bug-tar] tar 1.23: Problem under Solaris 10 - incorrect Ustar header contents

[Armistead, Jason]

Hi everyone
 
We're using Solaris 10 Sparc with GCC 3.4.3 (from Sun Freeware) installed as 
the C compiler.
 
Using tar 1.14 and 1.23, I discovered that I was having problems with opening 
the tar archives under 7-Zip or WinZIP on Windows XP.  I can't recall where I 
got tar 1.14 (I think it was from the Sun Freeware site).  As for tar 1.23, I 
downloaded and did the usual
 
./configure
make
 
routine to get things built, then just used the resultant tar executable 
(skipping the "make install" step so that I didn't overwrite my existing 
version).
 
7-Zip claims my tar files are not archives (without giving any clues), while 
WinZIP 12.0 tells me it has problems after record X (whatever number it decides 
to throw up, but always consistent for a given file).
 
I was careful to transfer them from Solaris to Windows XP using FTP in BINARY 
mode.  I even did MD5 digests on both systems and compared the results - both 
identical !
 
So, I looked at the contents of the tar files in hexadecimal, using HHD 
Software's excellent Free Hex Editor Neo (truly amazing functionality !).  What 
I noticed is that the tar header is not formed correctly.
 
I'm building a UStar formatted archive (the default for tar) It's supposed to 
contain the Ustar magic indicator at offset 257 followed by a null.  But, what 
I get is "ustar" followed by a space (20 hex).  Then at offset 263, it's 
supposed to be the Ustar version "00", but I am seeing a space (20 hex) then a 
null (00 hex).
 
When I look at the tar source code, specifically create.c, I see the following:
 
/* Write a "private" header */
union block *
start_private_header (const char *name, size_t size, time_t t)
{
  union block *header = find_next_block ();
  memset (header->buffer, 0, sizeof (union block));
  tar_name_copy_str (header->header.name, name, NAME_FIELD_SIZE);
  OFF_TO_CHARS (size, header->header.size);
  TIME_TO_CHARS (t, header->header.mtime);
  MODE_TO_CHARS (S_IFREG|S_IRUSR|S_IWUSR|S_IRGRP|S_IROTH, header->header.mode);
  UID_TO_CHARS (getuid (), header->header.uid);
  GID_TO_CHARS (getgid (), header->header.gid);
  MAJOR_TO_CHARS (0, header->header.devmajor);
  MINOR_TO_CHARS (0, header->header.devminor);
  strncpy (header->header.magic, TMAGIC, TMAGLEN);
  strncpy (header->header.version, TVERSION, TVERSLEN);
  return header;
}
 
And in the default POSIX archive case, "header" is represented by a struct
 
/* POSIX header.  */
struct posix_header
{    /* byte offset */
  char name[100];  /*   0 */
  char mode[8];   /* 100 */
  char uid[8];   /* 108 */
  char gid[8];   /* 116 */
  char size[12];  /* 124 */
  char mtime[12];  /* 136 */
  char chksum[8];  /* 148 */
  char typeflag;  /* 156 */
  char linkname[100];  /* 157 */
  char magic[6];  /* 257 */
  char version[2];  /* 263 */
  char uname[32];  /* 265 */
  char gname[32];  /* 297 */
  char devmajor[8];  /* 329 */
  char devminor[8];  /* 337 */
  char prefix[155];  /* 345 */
    /* 500 */
};
 
So I'm a bit unsure of how the null after the magic "ustar" identifier and the 
version string are getting wiped out.
 
Has anyone seen this weirdness before ?  Maybe there's a bug in the GCC 3.4.3 
compiler on Solaris/Sparc, or else something weird's happening with the 
strncpy() calls.
 
Any ideas ?
 
Thanks,
Jason