First, IDT = Iomega Ditto Tools; I've grown tired of typing the whole
thing all the time :-)
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).
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!
Anyway, I went to download ftape-tools again, and discovered a new
version, 1.08. The vtblc code has now changed a bit - it's been
libraryized :-)
Except that I can't compile it. I get:
.libs/libftvt.so: undefined reference to `minor'
when linking the library (to build it).
I did a bit of grepping; lines 204 and 207 of libftvt.c appear to have
the only reference to minor - and I assume it's a macro which extracts
the minor device number, but I can't find the header file it's defined
in, and it appears to be a function :-( Not knowing the kernel very
well, I'm kind of stuck; however, it's just a check for obsolency (or
so I think), so I cut it out - is my computer going to blow up? :-)
Other bits don't compile either for the same reason; so it'd be nice
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 :-(
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.
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.
Does this mean that this particular difference that fmt_big has
doesn't apply to the /Ditto Max( Pro)?/? Or is there just an
off-by-one here - adding a 1 on to volmues[vtbl_cnt].end appears to
make vtblc's output match what I'm getting from reading the volumes.
(For anyone who cares, a compressed volume should start with eight
0x00s, then an unsigned 16 slightly under 29k; an uncompressed volume
starts with 0xcc 0x33 0xcc 0x33)
That `bug' always did seem a bit strange to me; maybe this is the
solution? So, in summary, I think that either:
(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;
(I would do a patch, but it seems kind of small and I didn't save the
old file :-(
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.
(2) This behaviour only exhibits itself on the Ditto Max, Ditto Max
Pro, or both (after all, they don't have to strictly [or even loosely]
follow any standards).
If it's (1), then that patch needs to be applied. If (2), then we need
some way of detecting the /Ditto Max( Pro)?/ tape.
A program which uses the incorrect vtblc data will, instead of
appending to the tape, overwrite the last part of the previous
archive(s).
If I'm right in my understanding that amanda uses vtblc, relevant
people may need to take note of this (but check that I'm not wrong
about this whole thing first :-)
Robie.
--
Robie Basak <[EMAIL PROTECTED]>
PGP signature
