[Info-vax] VMSTAR update candidate?

[Steven Schweda]

>    I thought that I had tested this better, but there seems to
> be a bug in the >8GB file size storage when creating an
> archive.  I'll see if I can straighten that out for "-pre7".

   Either I missed something obvious (again) or the GNU "tar"
format changed while I wasn't looking, or something.  A small
change to vms2tar.c seems to make "tar (GNU tar) 1.22" on my
Solaris system happy enough:

sol# bzip2 -dc ../sg8s_7.tar.bz2 | gtar xfv -
gtar: Record size = 10 blocks
small1
gt8GB
small2
sol# ls -l
total 16785444
-rw-r--r--   1 adm      other    8589938688 Nov 10  2007 gt8GB
-rw-r--r--   1 adm      other          8 Oct  1 10:02 small1
-rw-r--r--   1 adm      other          8 Sep 30 16:32 small2


ALP $ gdiff -u ../V3R5_PRE6/vms2tar.c vms2tar.c
--- ../V3R5_PRE6/vms2tar.c      2009-05-06 15:18:10 -0500
+++ vms2tar.c   2009-10-02 17:07:25 -0500
@@ -169,11 +169,12 @@
             vt_size_t bc;

             bc = bytecount;
-            for (ndx = 11; ndx >= 0; ndx--)
+            for (ndx = 11; ndx > 0; ndx--)
             {
                 header.count[ ndx] = bc& 0xff;      /* Size (large,
binary). */
                 bc = bc>> 8;
             }
+            header.count[ 0] = 0x80;
         }
         else
 #endif /* def _LARGEFILE */

0x80 instead of 0x00 in that spot agrees with what that GNU
"tar" does when creating an archive bigger than 8GB, so it's
probably not amazing that that's what it wants to see there.
I should probably read more.

Finding the next bug is now _your_ responsibility.