Hallo,
I have three tapes of which the header segments were damaged by ftape
4.02 and am now trying to repair them.
I have inserted the patch Claus has sent. My ftape-read.c reads like this
now:
void ftape_zap_read_buffers(ftape_info_t *ftape)
{
if (ftape->fdc->ops && ftape->fdc->ops->terminate_dma) {
(void)ftape->fdc->ops->terminate_dma(ftape->fdc,
no_error);
}
fdc_zap_buffers(ftape->fdc);
ftape_reset_buffer(ftape);
}
And ftape-write.c:
void ftape_zap_write_buffers(ftape_info_t *ftape)
{
buffer_struct *pos = ftape->fdc->buffers;
TRACE_FUN(ft_t_flow);
if (ftape->fdc->ops && ftape->fdc->ops->terminate_dma) {
(void)ftape->fdc->ops->terminate_dma(ftape->fdc,
no_error);
}
if (pos == NULL) {
TRACE_EXIT;
}
do {
pos->status = done;
pos = pos->next;
} while (pos != ftape->fdc->buffers);
ftape_reset_buffer(ftape);
TRACE_EXIT;
}
I then compiled and installed it and tried to "repair" one of the tape in
the following way resulting in the error message thereafter:
root@Johann(22)$ ftmt -f /dev/qft0 erase
block contained error not caught by CRC.
ftmt: /dev/qft0: I/O error
On the other two damaged tapes the result was:
root@Johann(24)$ ftmt -f /dev/qft0 erase
ftmt: /dev/qft0: I/O error
I then changed the permissions to
crw-rw-rw- 1 root root 27, 0 Jan 25 07:03 /dev/qft0
crw-rw-rw- 1 root root 27, 0 Jan 25 07:03 /dev/nqft0
resulting in the following:
root@Johann(50)$ ftmt -f /dev/qft0 erase
ftmt: /dev/qft0: Permission denied
root@Johann(51)$ ftmt -f /dev/nqft0 erase
ftmt: /dev/nqft0: Permission denied
Is there any hope of me being able to use those three tapes again.
Please cc to me as I am not subscribed to the list.
Johann
On 2 Nov 1998, Claus-Justus Heine wrote:
>
> I think I have found the reason for those header segments mysteriously
> erased by ftape. It was indeed a bug in ftape, however, I couldn't
> find it earlier as my external Ditto 3200 behave a little bit
> different.
>
> There is a command sequence which tells the tape drive to terminate
> the data transfer from the drives built-in memory to the tape drive's
> builtin FDC.
>
> Calling this command sequence in ftape_zap_write/read_buffers() solves
> the problem with the header segment erasures.
>
> I got my brother's external Ditto 2GB tape drive so I was able to
> track it down.
>
> With ftape-4.02, the following command sequence end up with a segment
> written full with zeroes. Right after loading the driver, you can try
> to
>
> tar -cvf /dev/qft0 /bin/bash # works fine
> tar -tvf /dev/qft0 # works fine, too
> tar -cvf /dev/qft0 /bin/bash # seems to work fine, but in fact the first
> # segment written to tape is filled with zeroes
> tar -tvf /dev/qft0 # consequently, doesn't work.
>
> By slightly modifying this command sequence, one ends up with a 100%
> fail-safe method to erase the first header segment:
>
> tar -cvf /dev/qft0 /bin/bash # works, if driver has been freshly loaded
> tar -tvf /dev/qft0 # works, to, isn't needed, probably.
> ftmt -f /dev/qft0 erase # zeroes the first header segment.
>
>
>
> So, if you are curious, please try the first example, not the second.
> I'll provide a patch, and the next 4.03 prerelease will have the fix
> already included. The fix is easy. Insert the following lines in
> ftape_zap_read_buffers() as well as ftape_zap_write_buffers() (in
> ftape/lowlevel/ftape-read.c and ftape/lowlevel/ftape-write.c):
>
> if (ftape->fdc->ops && ftape->fdc->ops->terminate_dma) {
> (void)ftape->fdc->ops->terminate_dma(ftape->fdc, no_error);
> }
>
> That's it.
>
> I have just "successfully" erased the first header segment of my brand
> new 1.8GB Ditto 2GB cartridge, running an ftape driver without the
> fix. Now I'm gonna restore it by erasing the cartridge again, this
> time WITH the suggested fix .... Seems to have fixed it. Now I eject
> the cartridge and re-insert it to get rid of the cached header segment
> ftape holds in memory ... Good. The first header segment is back.
>
> I suggest that you -- in case you want to try the bug-fix -- FIRST
> make a backup of the header segment. You can do so by running
>
> ftmt -f /dev/rawft0 rdftseg 0 > D2G.hseg
>
> This tries to read the first header segment. If the first header
> segment already is damaged, and you wasn't able to fix it, then use
>
> ftmt -f /dev/rawft0 rdftseg 1 > D2G.hseg
>
> Then try to hack ftape and apply the fix, or wait for my patch or use
> the next (not yet released) pre-release of ftape-4.03. With the fix
> ftape shouldn't damage the header segments any more. I'm pretty sure
> that the bug fix works, because I can reliably reproduce the buggy
> behaviour of ftape, which vanishes as soon as I compile in the fix and
> use the modified ftape driver.
>
> Cheers
>
> Claus
>
>
> --
> Claus-Justus Heine
> [EMAIL PROTECTED]
> http://www.math1.rwth-aachen.de/~heine/
>
> Ftape - the Linux Floppy Tape Project
> WWW : http://www.math1.rwth-aachen.de/~heine/ftape/
> Mailing-list: [EMAIL PROTECTED]
>
--------------------------------------------------------------------------
| Johann Spies Windsorlaan 19 |
| [EMAIL PROTECTED] 3201 Pietermaritzburg |
| Tel/Faks Nr. +27 331-46-1310 Suid-Afrika (South Africa) |
--------------------------------------------------------------------------
"My little children, let us not love in word, neither
in tongue; but in deed and in truth."
I John 3:18
