Hi Robie,
> Good news, my decompression implementation now appears to be working
> smoothly, now it's just a case of parsing the header segments and
> volume table (vtblc already does this, I'm just snitching the code :-)
> and also parsing the actual QIC-113 bit (the easier bit).
Fine.
> 4 months, and I may have finally figured out what this 'ftape:
> Discrepancy between Iomega Ditto Tools' segments and ftape's?' is all
> about.
????
> Having typed:
> cp vtblc.[ch]
> I accidentally hit the ENTER key. Whoops!
Unix _is_ user-friendly ... :-)
> Except that I can't compile it. I get:
> .libs/libftvt.so: undefined reference to `minor'
> when linking the library (to build it).
Mmmh. Let me try
nm .libs/libftvt.so|grep minor
This yields nothing! Oops. Ok. "minor()" is a macro which is defined
(on my system) in /usr/include/sys/sysmacros.h. This file is included
by /usr/include/sys/types.h if __USE_BSD ist defined. This should be
the case if one runs gcc without any other C standard requirement,
i.e. without any of the -ansi etc. switches.
> Other bits don't compile either for the same reason; so it'd be nice
Are there other undefined symbols?
> if I could get it to compile properly. I think that the wrong header
> file may be being included, or that an incorrect library is being
> linked with it. I should be able to sort this out myself, if I knew
> which library/include it was. grepping for 'minor' seems to bring up
> too many red herrings :-(
So this is the solution:
a) Check that the minor() macro is defined in some file under
/usr/include/. Probably somewhere under /usr/include/sys/.
b) Try to determine how to include that header file. On my system
(glibc-2.1) a "grep sysmacros.h /usr/include/sys/*.h" showed that
it was included by /usr/include/sys/types.h. Reading that file
revealed that is included only if __USE_BSD is defined.
c) Check the command line switches of gcc. If in doubt, send me the
output of the make command (one line where gcc is executed).
d) If still clueless, try to run the make command with
make CC="gcc -D_GNU_SOURCE"
In any case, this is a matter of compiler/libc incompatibilities. At
worst I'll add some extra definitions so that the stuff will compile.
For this I need a list of all undefined symbols and/or compiler
warnings. Thanks.
> Anyway, as I was looking through this code, I found something very
> suspicious, lines 401-405 of libftvt.c:
> if (fmt_code == fmt_big) {
> volumes[vtbl_cnt].start = end_seg + 1;
> volumes[vtbl_cnt].end = (end_seg +
> volumes[vtbl_cnt].ftvt_space);
> end_seg = volumes[vtbl_cnt].end;
>
> /proc/ftape/0/cartridge reports my fmt-code as 6 (ie. fmt_big, I have
> a Ditto Max Pro). Is this where the problem is? It looks to me that
> the segment numbers are being adjusted here.
The exact format of a volume table entry depends on the format
code. "fmt_big" means more thatn 2^16 segments per cartridge.
Originally the starting and ending segment of a volume were stored as
16-bit numbers. Clearly, this does not work any longer if the
cartridge holds more than 2^16 segments. Therefore with a "fmt_big"
cartridge the volume table format is altered slightly: not the
starting segment is stored, but simply the number of segment occupied
by the volume -- as 32 bit number, occupying the two consecutive
fields which hold the starting and ending segment numbers for other
format codes.
> This looks exactly like the problem I had initially where the segment
> numbers given by vtblc didn't quite match the segment numbers where
> the volumes appeared to start, using MTIOCFTRDSEG. My solution was to
> subtract the entry (0-based) number from the given segment start
> number to get the real one. I had thought that this was a problem
> with IDT as I believed that vtblc was just reporting the numbers
> direct without interpretation.
> (1) This is a bug in vtblc, corrected by adding that 1 on so those
> lines appear as follows:
>
> if (fmt_code == fmt_big) {
> volumes[vtbl_cnt].start = end_seg + 1;
> volumes[vtbl_cnt].end = (end_seg + 1 +
> volumes[vtbl_cnt].ftvt_space);
> end_seg = volumes[vtbl_cnt].end;
Oops. Maybe this _is_ indeed a bug.
> Looking at it, this seems more likely (sorry Claus :-) Assuming that
> ftvt_space refers to the size of the volume, then the ending segment
> of the archive is either ftvt_space + start, or end_seg + 1.
No. The end_seg is the last segment of this volume. Say ftvt_space is
20. The first segment is 31. Then the last segment is _NOT_ 51, but
50. Think about it.
What I'm thinking of is that maybe the IDT write a copy of the volume
table segment right after each volume. I remember that something like
this was mentioned in some of the QIC standards for SCSI tapes. Maybe
I just got it wrong.
Can please extract the segment right after the first volume (with the
MTIOCRDFTSEG ioctl) and send me the output? This will shine some light
on it. Maybe I get a copy of the Ditto tools and check myself.
Thanks for the bug report
Claus
--
Claus-Justus Heine
[EMAIL PROTECTED]
http://www.instmath.rwth-aachen.de/~heine/
Ftape - the Linux Floppy Tape Project
Home Page : http://www.instmath.rwth-aachen.de/~heine/ftape/
Mailing-list: [EMAIL PROTECTED]
