🚀 go-pugleaf

There seems to be a bug in version 1.10 of gnutar concerning 
large files being split across volumes of a multi volume archive.

I'm pretty sure the bug has got to do with the writing of the 
header.offset value in the record which is written at the beginning
of the subsequent volumes.  Here is the data I have gathered, starting
with a hex dump of the start of the second volume...

0000    75 73 72 32 2f 62 62 78  2f 78 66 69 6c 2f 58 4d   usr2/bbx/xfil/XM
0010    44 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00   D...............
0020    00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00   ................
*
0070    00 00 00 00 00 00 00 00  00 00 00 00 20 20 20 31   ............   1
0080    30 34 34 36 30 30 30 20  00 00 00 00 00 00 00 00   0446000 ........
0090    00 00 00 00 20 20 35 35  32 36 00 20 4d 00 00 00   ....  5526. M...
00a0    00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00   ................
*
0170    00 20 20 20 31 33 31 31  33 30 30 30 20 00 00 00   .   13113000 ...
0180    00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00   ................
*
0240    00 00 48 45 41 54 48 45  52 0a 30 35 38 0a 30 32   ..HEATHER.058.02
0250    0a 20 20 30 31 30 32 30  33 20 20 32 31 32 32 32   .  010203  21222
0260    33 32 34 20 20 33 31 0a  46 69 6c 65 20 4d 61 69   324  31.File Mai
0270    6e 74 65 6e 61 6e 63 65  20 20 20 20 20 20 20 20   ntenance        
0280    20 20 20 20 20 20 42 75  64 67 65 74 20 46 69 6c         Budget Fil
0290    65 20 4d 61 69 6e 74 65  6e 61 6e 63 65 20 20 20   e Maintenance   
02a0    20 20 20 20 42 75 64 67  65 74 20 46 69 6c 65 20       Budget File 
02b0    4d 61 6e 69 70 75 6c 61  74 69 6f 6e 20 20 20 20   Manipulation    
02c0    20 20 56 6f 6c 75 6d 65  20 46 69 6c 65 20 4d 61     Volume File Ma
02d0    69 6e 74 65 6e 61 6e 63  65 20 20 20 20 20 20 20   intenance       

I stuck the following code into fl_read() to try and debug this problem...

      if(real_s_totsize-real_s_sizeleft!=from_oct(1+12,head->header.offset)) {
->printf("real_s_totsize=%ld, real_s_sizeleft=%ld, head->header.offset=%s\n",
       real_s_totsize,real_s_sizeleft,head->header.offset);
        msg("This volume is out of sequence");
        --volno;
        goto try_volume;
      }

which yielded the following results...

real_s_totsize=5169664, real_s_sizeleft=2182144, head->header.offset=   13113000 
gnutar_debug: This volume is out of sequence

so what all this means is that the value which was written into header.offset
when the archive was created was 13113000 (binary 1011001001011000000000) and 
the value expected there upon reading the record is 5169664-2182144=13313000
(binary 1011011001011000000000).
Notice, if you look at the binary of these two numbers side by side they look 
like this...
00101100 10010110 00000000
00101101 10010110 00000000

they are identical execpt for bit one of the left most byte.  This is where the
error is, and I would guess that the bit is getting screwed up when the "amount
left to write" figure is coverted to octal and written to the archive on
creating the archive.  

Unfortunately, I don't have enough grasp on the whole process to further debug
the problem.  Any help would be greatly appreciated.

thanx

brian

-- 
Brian J. Murrell                                        brian@ilinx.wimsey.bc.ca
InterLinx Support Services, Inc.                        uunet!van-bc!ilinx!brian
North Vancouver, B.C.
        Platform and Brand Independent UNIX Support - R3.2 - R4 - BSD