-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi,
I'm (trying) to write a user-space program which can restore tapes
written with Iomega Ditto Tools in Windows or similar (QIC-113,
anyway).
I've found a discrepancy in the volume table I'm reading using vtbls
(binary examination with a hex editor and /dev/nrawft0 matches it)
and the data actually stored on the tape - I'm hoping that someone
can enlighten me as to whether this is a problem with ftape or Ditto
Tools (all the evidence points away from ftape IMHO).
I've got a tape with 55 archives on it, all saved using the 'Full
backup' in Ditto tools. Excerpts from `vtbls --print=parsable` are as
follows (in order, whitespace added to make easier to read):
ENTRY 0
START 3
END 59
FLAG_DIRECTORY_LAST 1
DIRECTORY_SIZE 195
DATA_SIZE 1669661
ENTRY END
ENTRY 1
START 60
END 316
FLAG_DIRECTORY_LAST 1
DIRECTORY_SIZE 192
DATA_SIZE 7621009
ENTRY END
...
ENTRY 51
START 28353
END 28353
FLAG_DIRECTORY_LAST 1
DIRECTORY_SIZE 456
DATA_SIZE 761
ENTRY END
Basically, entries 0-50 were there already, I added 51-54 to try to
understand the format (ie. 51 uncompressed, 52 exactly the same thing
but compressed etc).
I tried to read segment 28353 (the beginning of entry 51) using
ftmt -f /dev/nftape asf 51 then dd, and also using
ftmt rdftseg 28353, both returned the same result (cmp), which
appeared to be the middle of a previous archive (being a full
segment, I was able to decompress it, and it then resembled text from
some data I recognised).
I read segment 3, and found the beginning of the first archive, but
segment 60 appeared to be the last segment of the first archive, not
the beginning of the second. The second archive actually started at
61.
Tracing through, assuming that each archive contains 1 more segment
than the volume table states, I calculated that entry 51 actually
starts at segment 28404, which gives the correct result (I see the
archive I stored in Ditto Tools).
Phew.
Now the problem - is this a bug in my brain, Ditto Tools or ftape? It
looks to me like Iomega did a kludge and take into account this
discrepancy when adding an archive, but still write the incorrect
volume table nontheless (perhaps to retain compatiblity, but I don't
really see how that would work). If this is a bug in ftape, then the
only way that this could be happening would be if ftape drops a
segment at every boundary between entries - even in raw mode.
I need to know this so that I know whether to implement this kludge
in my program (which is progressing, but the decompression's still a
bit screwy :-)
Also, if I do, then I'll need to know when to do it. I'd be grateful
if anyone can reproduce this, and if not, then how I can identify it
(it might be in the VENDOR_EXTENSION code, the only consistency in my
archives are that they always start with 0x71 and that some bytes
are always 0).
Thanks,
Robie.
- --
Robie Basak <[EMAIL PROTECTED]>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.1 (GNU/Linux)
Comment: For info see http://www.gnupg.org
iD8DBQE4zVfQ0EnIYMyLeMQRAn86AJ48gIzBtNnOI9EifvSvS8v7rbgzVQCePy4k
ig1dGec3MIAy6K+daCj2qIs=
=Xxw6
-----END PGP SIGNATURE-----
