Hi Robie,
> First, I apologise for sending you a 300K+ email without compressing
> it; I only realized it was that big when it tried to fit down my 56K
> modem :-)
No problem.
>
> On Wed, Jul 12, 2000 at 04:17:17AM +0200, Claus-Justus Heine wrote:
>
> [...]
>
> > > What do I have to do, exactly? I tried -lftvt, but that gives me:
> > > /tmp/ccNA5ZQx.o: In function `main':
> > > /tmp/ccNA5ZQx.o(.text+0x251): undefined reference to `ftvt_open(char
> > > const *, unsigned int)'
> >
> > Can it be you are using C++? I'll have to add the following to ftvt.h:
>
> [...]
>
> > I bet you are using C++ ...
>
> You're right - thanks. I should have thought of that and fixed it
> myself; I guess I'm too used to the extern "C"s already being done for
> me.
Me to, normally.
> > Just to determine whether they forget to count the directory segments,
> > or are simply off by one.
>
> Unfortunately not; I'll ask someone who offered testing help to me a
> while back (my Windows partition is probably too small).
I think it is just the A-B+1 weirdness ...
> > However, it is clearly a bug in IDT and QBackup. The QIC-113 standard
> > is clear in this respect: bytes 4 to 7 of the volume table entry hold
> > the ENTIRE number of segments used by the volume. And a volume
> > (according to QIC 113) consists of the data section AND the directory
> > section.
>
> Does QBackup claim to support QIC-113?
No. But if it is not a bug then it is a stupid feature.
> > So what to do. Either go adapt the buggy behaviour of Seagate's
> > QBackup and Iomegas IDT. Or find a way to determine if how has created
> > the volumes.
> >
> > I suspect they simply took the last segment and substracted the number
> > of the first segment. And this is WRONG.
> >
> > Ideas?
>
> Appending to a tape seems to be the main problem here; we need to know
> if the end segment is correct or not, otherwise we could corrupt data.
>
> Are there any implementations with code 6, other that zftape and
> vtblc, which handle this correctly?
I tried to test "Backup Exec" last night. But it refused to work with
my tape drive.
> If not, how about we always write the volume table correctly (as a
> broken implementation appending to the tape will then skip a segment,
> correct implementations will start at the right place), and when
> reading the table assume that it is wrong, unless written by us (using
> a vendor extension code, then we append in the right place for broken
> implementations, and skip a segment for correct implementations)?
There already is a vendor extension code which identifies volumes
written by ftape (you probably know that).
> If there is another implementation which is correct, then we should
> contact them, as they are also affected. If we could agree on a vendor
> extension to notify ourselves that the volume info for that volume is
> correct, then this would work (otherwise segments would be
> unnecessarily skipped).
>
> This is the only solution I can come up with which works without user
There is another problem: all ftape version including ftape-4.03
didn't take that IDT feature into account. Therefore it doesn't
suffice to identify a volume written by ftape. We have to distinguish
between volumes written by ftape version which did not work around
that IDT feature and volume written by ftape version which do work
around the IDT feature.
But this means we can as well implement the IDT feature in ftape and
work around the behaviour of old ftape versions. Then IDT and QBackup
and maybe others will decode the size of volumes written ftape "wrongly
correctly" and everything is fine.
> intervention; the other option is to add a ft_fdc_broken_volume_table
> option to zftape and a --with-broken-volume-table to vtblc :-)
Oh well ...
> What do you think about me asking QIC regarding this problem and to
> see if they can get us into contact with everyone using QIC-113 (or at
> least do a new revision of the specs pointing this common error out);
> as really speaking this affects everyone (assuming that there are
> broken implementations which say that they support the relevant QIC
> specs)? I can't think of any way in which buggy implementations can be
> fixed to function properly, without tagging the correctly written
> volume tables in this way.
Good idea.
> Other matters; I'd like to modify libftvt a bit, spitting ftvt_read
> into a function to read the header and volume table segments into
> buffers, and another to parse the volume table into *volumes given the
> buffers - and to modify ftvt_read to call each in turn to keep it's
> behaviour the same.
>
> I need it to give the header segment to ftfmt-bsm.c to get the bad
> sector map, and it seems a waste to read the segment twice (especially
> as getting the header segment isn't as simple as just reading it).
>
> Also, how about if I integrate bsm processing into libftvt (from
> ftfmt-bsm.c)?
>
> Any comments/suggestions/warnings/threats before I begin? :-)
Do whatever you need to do. I should give you write access to the CVS
repository. Working on it.
Claus
--
Claus-Justus Heine Phone: +49 241 804923
Institute for Mathematics
Templergraben 55 Fax: +49 241 8888 323
RWTH Aachen
52062 Aachen, Germany
