home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #27 / NN_1992_27.iso / spool / gnu / utils / bug / 2090 < prev    next >
Encoding:
Text File  |  1992-11-20  |  3.8 KB  |  86 lines
  1. Newsgroups: gnu.utils.bug
  2. Path: sparky!uunet!cis.ohio-state.edu!ilinx.wimsey.bc.CA!brian
  3. From: brian@ilinx.wimsey.bc.CA
  4. Subject: bug with tar 1.10 multi-volume extents
  5. Message-ID: <1992Nov21.002651.24776@ilinx.wimsey.bc.ca>
  6. Sender: gnulists@ai.mit.edu
  7. Organization: InterLinx Support Services Inc.
  8. Distribution: gnu
  9. Date: Sat, 21 Nov 1992 00:26:51 GMT
  10. Approved: bug-gnu-utils@prep.ai.mit.edu
  11. Lines: 73
  12.  
  13. There seems to be a bug in version 1.10 of gnutar concerning 
  14. large files being split across volumes of a multi volume archive.
  15.  
  16. I'm pretty sure the bug has got to do with the writing of the 
  17. header.offset value in the record which is written at the beginning
  18. of the subsequent volumes.  Here is the data I have gathered, starting
  19. with a hex dump of the start of the second volume...
  20.  
  21. 0000    75 73 72 32 2f 62 62 78  2f 78 66 69 6c 2f 58 4d   usr2/bbx/xfil/XM
  22. 0010    44 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00   D...............
  23. 0020    00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00   ................
  24. *
  25. 0070    00 00 00 00 00 00 00 00  00 00 00 00 20 20 20 31   ............   1
  26. 0080    30 34 34 36 30 30 30 20  00 00 00 00 00 00 00 00   0446000 ........
  27. 0090    00 00 00 00 20 20 35 35  32 36 00 20 4d 00 00 00   ....  5526. M...
  28. 00a0    00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00   ................
  29. *
  30. 0170    00 20 20 20 31 33 31 31  33 30 30 30 20 00 00 00   .   13113000 ...
  31. 0180    00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00   ................
  32. *
  33. 0240    00 00 48 45 41 54 48 45  52 0a 30 35 38 0a 30 32   ..HEATHER.058.02
  34. 0250    0a 20 20 30 31 30 32 30  33 20 20 32 31 32 32 32   .  010203  21222
  35. 0260    33 32 34 20 20 33 31 0a  46 69 6c 65 20 4d 61 69   324  31.File Mai
  36. 0270    6e 74 65 6e 61 6e 63 65  20 20 20 20 20 20 20 20   ntenance        
  37. 0280    20 20 20 20 20 20 42 75  64 67 65 74 20 46 69 6c         Budget Fil
  38. 0290    65 20 4d 61 69 6e 74 65  6e 61 6e 63 65 20 20 20   e Maintenance   
  39. 02a0    20 20 20 20 42 75 64 67  65 74 20 46 69 6c 65 20       Budget File 
  40. 02b0    4d 61 6e 69 70 75 6c 61  74 69 6f 6e 20 20 20 20   Manipulation    
  41. 02c0    20 20 56 6f 6c 75 6d 65  20 46 69 6c 65 20 4d 61     Volume File Ma
  42. 02d0    69 6e 74 65 6e 61 6e 63  65 20 20 20 20 20 20 20   intenance       
  43.  
  44. I stuck the following code into fl_read() to try and debug this problem...
  45.  
  46.       if(real_s_totsize-real_s_sizeleft!=from_oct(1+12,head->header.offset)) {
  47. ->printf("real_s_totsize=%ld, real_s_sizeleft=%ld, head->header.offset=%s\n",
  48.        real_s_totsize,real_s_sizeleft,head->header.offset);
  49.         msg("This volume is out of sequence");
  50.         --volno;
  51.         goto try_volume;
  52.       }
  53.  
  54. which yielded the following results...
  55.  
  56. real_s_totsize=5169664, real_s_sizeleft=2182144, head->header.offset=   13113000 
  57. gnutar_debug: This volume is out of sequence
  58.  
  59. so what all this means is that the value which was written into header.offset
  60. when the archive was created was 13113000 (binary 1011001001011000000000) and 
  61. the value expected there upon reading the record is 5169664-2182144=13313000
  62. (binary 1011011001011000000000).
  63. Notice, if you look at the binary of these two numbers side by side they look 
  64. like this...
  65. 00101100 10010110 00000000
  66. 00101101 10010110 00000000
  67.  
  68. they are identical execpt for bit one of the left most byte.  This is where the
  69. error is, and I would guess that the bit is getting screwed up when the "amount
  70. left to write" figure is coverted to octal and written to the archive on
  71. creating the archive.  
  72.  
  73. Unfortunately, I don't have enough grasp on the whole process to further debug
  74. the problem.  Any help would be greatly appreciated.
  75.  
  76. thanx
  77.  
  78. brian
  79.  
  80. -- 
  81. Brian J. Murrell                                        brian@ilinx.wimsey.bc.ca
  82. InterLinx Support Services, Inc.                        uunet!van-bc!ilinx!brian
  83. North Vancouver, B.C.
  84.         Platform and Brand Independent UNIX Support - R3.2 - R4 - BSD
  85.  
  86.