home *** CD-ROM | disk | FTP | other *** search
- Newsgroups: gnu.utils.bug
- Path: sparky!uunet!usc!zaphod.mps.ohio-state.edu!cis.ohio-state.edu!ilinx.wimsey.bc.CA!brian
- From: brian@ilinx.wimsey.bc.CA
- Subject: tar 1.10 bug with big files, multi-volume update
- Message-ID: <1992Nov23.223255.29801@ilinx.wimsey.bc.ca>
- Sender: gnulists@ai.mit.edu
- Organization: InterLinx Support Services Inc.
- Distribution: gnu
- Date: Mon, 23 Nov 1992 22:32:55 GMT
- Approved: bug-gnu-utils@prep.ai.mit.edu
- Lines: 35
-
- Hey there,
-
- I sent a bug report last week regarding tar v1.10 and large
- files across multivolumes. Well I have some more information.
-
- I put in some debug statements to find the values of various
- variables while the archive was being created. The results are
- interesting. When creating the archive, I got the following
- values when changing tapes...
-
- real_s_totsize=5169664, real_s_sizeleft=2402304, head->header.offset= 12235000
-
- so it appears that there is not an error with creating the header.offset
- value as I originally suspected. Here are the same variables when the
- archive was read back...
-
- real_s_totsize=5169664, real_s_sizeleft=2467840, ar_block->header.offset= 1223
- 5000
-
- the value of real_s_sizeleft is 65536 bigger when reading that it was when
- writing. Why would this be??
-
- What is real_s_sizeleft?? I suspect it is the number of bytes left to read
- to make the current file complete.
-
- any ideas??
-
- 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
-
-