25 Jan
2017
25 Jan
'17
2:24 p.m.
Hi,
We have a friend with a "tape" (DDS, DLT, or LTO ... don't know which yet)
to which was written a system backup. Thousands of files, with an EOF
between each file, and a double EOF + EOT at the end.
The problem:
They then accidentally overwrote the start of the tape yesterday
with about 1 KB of data, plus EOT.
(By EOT I mean the "logical end-of-tape" indicator placed there
by the drive firmware when a tape is rewound / unloaded after
it's been written to.)
So, we want to try to recover the files after that 1 KB + EOT.
On reel tape, no problem. I'd read until I hit the double EOF, and then
skip the partial file (by looking for the next EOF), and then...gravy.
But, DDS/DLT/LTO drives won't let me get past that darn logical end-of-tape.
Are there solutions anyone can suggest?
I've only heard of two approaches:
1. find a drive with modified firmware, one that treats an EOT like an EOF
While I heard some existed for DDS-1 drives, that lead was 20 years old :)
2. insert tape, start writing (at the start), write until I'm sure I've
written over the area where the EOT was,
power cycle the drive
read from the start, skipping over the data I just wrote, handle the
possible corrupted record, and the I've got good data from past the EOT
(note that this method loses a small amount of old data past the EOT
that we overwrote).
On DDS drives, I used this technique once or twice successfully,
although I seem to recall I couldn't do the "read until I get to
the good stuff" because of the probability of a bad record on the
tape (where the power fail was) ... but the solution was to load the tape
and then say "skip forward 3 EOFs", and the skip-to-EOF would
quietly ignore (usually) any bad record before the EOF.
BTW, if this is DDS, it's unlikely to be newer than DDS-4 (but possible),
if it's DLT, it's likely one of the first two or three generations,
and if it's LTO, it's extremely unlikely to be anything other than LTO-1.
thanks,
Stan
25 Jan
25 Jan
3:08 p.m.
Hi Stan
As a thought, a piece of magic mending tape?
Dwight
________________________________
From: cctalk <cctalk-bounces at classiccmp.org> on behalf of Stan Sieler <sieler
at allegro.com>
Sent: Wednesday, January 25, 2017 11:24:06 AM
To: cctalk at classiccmp.org
Subject: Looking to read past EOT on DDS/DLT/LTO
Hi,
We have a friend with a "tape" (DDS, DLT, or LTO ... don't know which yet)
to which was written a system backup. Thousands of files, with an EOF
between each file, and a double EOF + EOT at the end.
The problem:
They then accidentally overwrote the start of the tape yesterday
with about 1 KB of data, plus EOT.
(By EOT I mean the "logical end-of-tape" indicator placed there
by the drive firmware when a tape is rewound / unloaded after
it's been written to.)
So, we want to try to recover the files after that 1 KB + EOT.
On reel tape, no problem. I'd read until I hit the double EOF, and then
skip the partial file (by looking for the next EOF), and then...gravy.
But, DDS/DLT/LTO drives won't let me get past that darn logical end-of-tape.
Are there solutions anyone can suggest?
I've only heard of two approaches:
1. find a drive with modified firmware, one that treats an EOT like an EOF
While I heard some existed for DDS-1 drives, that lead was 20 years old :)
2. insert tape, start writing (at the start), write until I'm sure I've
written over the area where the EOT was,
power cycle the drive
read from the start, skipping over the data I just wrote, handle the
possible corrupted record, and the I've got good data from past the EOT
(note that this method loses a small amount of old data past the EOT
that we overwrote).
On DDS drives, I used this technique once or twice successfully,
although I seem to recall I couldn't do the "read until I get to
the good stuff" because of the probability of a bad record on the
tape (where the power fail was) ... but the solution was to load the tape
and then say "skip forward 3 EOFs", and the skip-to-EOF would
quietly ignore (usually) any bad record before the EOF.
BTW, if this is DDS, it's unlikely to be newer than DDS-4 (but possible),
if it's DLT, it's likely one of the first two or three generations,
and if it's LTO, it's extremely unlikely to be anything other than LTO-1.
thanks,
Stan
5:16 p.m.
On Jan 25, 2017 12:24 PM, "Stan Sieler" <sieler at allegro.com> wrote:
We have a friend with a "tape" (DDS, DLT, or
LTO ... don't know which yet)
to which was written a system backup. Thousands of files, with an EOF
between each file, and a double EOF + EOT at the end.
The problem:
They then accidentally overwrote the start of the tape yesterday
with about 1 KB of data, plus EOT.
I hope someone can prove me wrong, but I think that short of a major effort
to hack the drive firmware, the data is gone. Modern tape drives are "too
smart" to allow reading past logical EOT, and the tape format is too
complex to allow fooling the firmware by any simple means.
6:04 p.m.
On 01/25/2017 02:16 PM, Eric Smith wrote:
On Jan 25, 2017 12:24 PM, "Stan Sieler"
<sieler at allegro.com> wrote:
With nothing left to lose, I suppose that one might overwrite the EOT
and then kill power during the write, then attempt to read backward from
the end of the tape.
I've never done it, but who knows?
--Chuck
We have a friend with a "tape" (DDS,
DLT, or LTO ... don't know
which yet) to which was written a system backup. Thousands of
files, with an EOF between each file, and a double EOF + EOT at the
end.
The problem: They then accidentally overwrote the start of the tape
yesterday with about 1 KB of data, plus EOT.
I hope someone can prove me wrong, but I think that short of a major
effort to hack the drive firmware, the data is gone. Modern tape
drives are "too smart" to allow reading past logical EOT, and the
tape format is too complex to allow fooling the firmware by any
simple means. 
6:07 p.m.
On Wed, Jan 25, 2017 at 3:04 PM, Chuck Guzis <cclist at sydex.com> wrote:
On 01/25/2017 02:16 PM, Eric Smith wrote:
Or do it the data recovery way -- find a broken drive with a working
transport, hookup a A/D to the tape heads, stream the tape, capture the
flux, decode.
Not necessarily easy, tho.
-- Charles
On Jan 25, 2017 12:24 PM, "Stan Sieler"
<sieler at allegro.com> wrote:
With nothing left to lose, I suppose that one might overwrite the EOT
and then kill power during the write, then attempt to read backward from
the end of the tape.
I've never done it, but who knows?
We have a friend with a "tape" (DDS,
DLT, or LTO ... don't know
which yet) to which was written a system backup. Thousands of
files, with an EOF between each file, and a double EOF + EOT at the
end.
The problem: They then accidentally overwrote the start of the tape
yesterday with about 1 KB of data, plus EOT.
I hope someone can prove me wrong, but I think that short of a major
effort to hack the drive firmware, the data is gone. Modern tape
drives are "too smart" to allow reading past logical EOT, and the
tape format is too complex to allow fooling the firmware by any
simple means. 
7:06 p.m.
On 1/25/2017 6:07 PM, Charles Anthony
wrote:
On Wed, Jan 25, 2017 at 3:04 PM, Chuck Guzis<cclist
at sydex.com> wrote:
Would it be possible to just physically
cut the 1kb + EOT portion of tape out,
and then attempt to read from
beginning? I suppose this would depend
on how the backup data is formatted on
the tape (using some kind of container
format with error checking, for instance).
- J.
On 01/25/2017 02:16 PM, Eric Smith wrote:
Or do it the data recovery way -- find a broken drive with a working
transport, hookup a A/D to the tape heads, stream the tape, capture the
flux, decode.
Not necessarily easy, tho.
-- Charles
On Jan 25, 2017 12:24 PM, "Stan
Sieler"<sieler at allegro.com> wrote:
With nothing left to lose, I suppose that one might overwrite the
EOT
and then kill power during the write, then attempt to read backward from
the end of the tape.
I've never done it, but who knows?
We have a friend with a "tape" (DDS,
DLT, or LTO ... don't know
which yet) to which was written a system backup. Thousands of
files, with an EOF between each file, and a double EOF + EOT at the
end.
The problem: They then accidentally overwrote the start of the tape
yesterday with about 1 KB of data, plus EOT.
I hope someone can prove me wrong,
but I think that short of a major
effort to hack the drive firmware, the data is gone. Modern tape
drives are "too smart" to allow reading past logical EOT, and the
tape format is too complex to allow fooling the firmware by any
simple means.
7:21 p.m.
On 01/25/2017 04:06 PM, js at cimmeri.com wrote:
Would it be possible to just physically cut the 1kb +
EOT portion of
tape out, and then attempt to read from beginning? I suppose this
would depend on how the backup data is formatted on the tape (using
some kind of container format with error checking, for instance).
The original description was a bit vague, so I don't know exactly what
kind of media or drive is being used. Some DDS drives (e.g. HP 35470)
support read-after-write if configured that way.
--Chuck
8:35 p.m.
----- Original Message -----
From: "Chuck Guzis" <cclist at sydex.com>
To: "General Discussion: On-Topic and Off-Topic Posts" <cctalk at
classiccmp.org>
Sent: Wednesday, January 25, 2017 7:21 PM
Subject: Re: Looking to read past EOT on DDS/DLT/LTO
On 01/25/2017 04:06 PM, js at cimmeri.com wrote:
--------------------
I've got a few DDS-4 (also some other format) drives headed for the scrapper one of
these days in case they're of interest to anyone; free for postage from Toronto.
m
Would it be possible to just physically cut the
1kb + EOT portion of
tape out, and then attempt to read from beginning? I suppose this
would depend on how the backup data is formatted on the tape (using
some kind of container format with error checking, for instance).
The original description was a bit vague, so I don't know exactly what
kind of media or drive is being used. Some DDS drives (e.g. HP 35470)
support read-after-write if configured that way.
--Chuck
7:07 p.m.
On Wed, 25 Jan 2017, Eric Smith wrote:
ISTR being able to successfully do `mt fsr' after `mt eod' with a DDS-4
drive and `mt tell' returned sensible status afterwards, so chances are it
might work. It might depend however on the particular drive, OS and
version of `mt' as there seem to be several implementations around; maybe
also whether firmware-driven data compression has been used. Plus my
memory may be fooling me as it's been years since. I think it's surely
worth trying though, as there's nothing to lose.
Maciej
The problem:
They then accidentally overwrote the start of the tape yesterday
with about 1 KB of data, plus EOT.
I hope someone can prove me wrong, but I think that short of a major effort
to hack the drive firmware, the data is gone. Modern tape drives are "too
smart" to allow reading past logical EOT, and the tape format is too
complex to allow fooling the firmware by any simple means. 
5:20 p.m.
Hi
I've had the same problem some years back, with a DDS-3, IIRC
I did some research, and the most reasonable outcome was that it was not
possible by normal means, because some algorithm reading synchronisation
data couldnt find out what was happening, so, the backup was ruined.....
/Nico
----- Original Message -----
From: Stan Sieler
To: cctalk at classiccmp.org
Sent: Wednesday, January 25, 2017 8:24 PM
Subject: Looking to read past EOT on DDS/DLT/LTO
Hi,
We have a friend with a "tape" (DDS, DLT, or LTO ... don't know which
yet)
to which was written a system backup. Thousands of files, with an EOF
between each file, and a double EOF + EOT at the end.
The problem:
They then accidentally overwrote the start of the tape yesterday
with about 1 KB of data, plus EOT.
(By EOT I mean the "logical end-of-tape" indicator placed there
by the drive firmware when a tape is rewound / unloaded after
it's been written to.)
So, we want to try to recover the files after that 1 KB + EOT.
On reel tape, no problem. I'd read until I hit the double EOF, and then
skip the partial file (by looking for the next EOF), and then...gravy.
But, DDS/DLT/LTO drives won't let me get past that darn logical
end-of-tape.
Are there solutions anyone can suggest?
I've only heard of two approaches:
1. find a drive with modified firmware, one that treats an EOT like an EOF
While I heard some existed for DDS-1 drives, that lead was 20 years old :)
2. insert tape, start writing (at the start), write until I'm sure I've
written over the area where the EOT was,
power cycle the drive
read from the start, skipping over the data I just wrote, handle the
possible corrupted record, and the I've got good data from past the EOT
(note that this method loses a small amount of old data past the EOT
that we overwrote).
On DDS drives, I used this technique once or twice successfully,
although I seem to recall I couldn't do the "read until I get to
the good stuff" because of the probability of a bad record on the
tape (where the power fail was) ... but the solution was to load the tape
and then say "skip forward 3 EOFs", and the skip-to-EOF would
quietly ignore (usually) any bad record before the EOF.
BTW, if this is DDS, it's unlikely to be newer than DDS-4 (but possible),
if it's DLT, it's likely one of the first two or three generations,
and if it's LTO, it's extremely unlikely to be anything other than LTO-1.
thanks,
Stan
--
I am using the free version of SPAMfighter.
SPAMfighter has removed 11142 of my spam emails to date.
Get the free SPAMfighter here: http://www.spamfighter.com/len
Do you have a slow PC? Try a Free scan
http://www.spamfighter.com/SLOW-PCfighter?cid=sigen
26 Jan
26 Jan
1:23 p.m.
On Wed, 25 Jan 2017, Nico de Jong wrote:
I did some research, and the most reasonable outcome
was that it was not
possible by normal means, because some algorithm reading synchronisation
data couldnt find out what was happening, so, the backup was ruined.....
Odd. This would imply you couldn't wind a tape past a medium error and
read what's behind, but I surely did it a couple of times with DDS tapes.
And this is exactly why I gave up on some proprietary (OSF/1 IIRC) `dump'
utility as it recorded an archive directory at the beginning making the
whole archive unusable if an error developed there. OTOH `tar' keeps file
information along with actual data spreading it across the archive, so any
medium error only causes the immediately affected file to be lost. Same
with `cpio' (except for the arcane CLI).
Maciej
1:46 p.m.
On 01/26/2017 10:23 AM, Maciej W. Rozycki wrote:
And this is exactly why I gave up on some proprietary
(OSF/1 IIRC)
`dump' utility as it recorded an archive directory at the beginning
making the whole archive unusable if an error developed there. OTOH
`tar' keeps file information along with actual data spreading it
across the archive, so any medium error only causes the immediately
affected file to be lost. Same with `cpio' (except for the arcane
CLI).
I find that the tar CLI in its full glory is no less arcane than the
creaky old cpio one.
tar used to be simple with few options.
--Chuck
1:59 p.m.
I find that the tar CLI in its full glory is no less
arcane than the
creaky old cpio one.
Ah, but what is "the tar CLI"? The POSIX one (which version?)? The
GNU one (which version?)? The V7 one? The one you learnt 15 years ago
and have trouble remembering anything beyond even now? :-)
tar used to be simple with few options.
True - and true of a lot more than just tar. And, if you are ready to
give up all the functionality correspnoding to the new options
(whichever set of new options you mean), it probably wouldn't be that
hard to tweak an old tar source into building today. _Also_ true of a
lot more than just tar....
/~\ The ASCII Mouse
\ / Ribbon Campaign
X Against HTML mouse at rodents-montreal.org
/ \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
9:01 p.m.
On Jan 26, 2017, at 1:23 PM, Maciej W. Rozycki
<macro at linux-mips.org> wrote:
On Wed, 25 Jan 2017, Nico de Jong wrote:
That's a good point. Can it really be true that a tape error that creates a false EOT
results in the loss of all remaining data? Surely the designers weren't *that*
stupid?
paul
I did some research, and the most reasonable
outcome was that it was not
possible by normal means, because some algorithm reading synchronisation
data couldnt find out what was happening, so, the backup was ruined.....
Odd. This would imply you couldn't wind a tape past a medium error and
read what's behind, but I surely did it a couple of times with DDS tapes.
9:29 p.m.
On 01/26/2017 06:01 PM, Paul Koning wrote:
That's a good point. Can it really be true that a
tape error that
creates a false EOT results in the loss of all remaining data?
Surely the designers weren't *that* stupid?
It happens. You can't skip over it or even space to EOT and then read
backwards. Some "intelligent" drives were really stupid.
--Chuck
27 Jan
27 Jan
12:01 p.m.
Also, prior to servo tracks on serpentine drives, there was a full-width
erase head, so if you rewrite from BOT, ALL tracks are erased as it rolls
to EOT.
The trick with killing power on 8mm and DAT works because they use
helical recording.
On 1/26/17 6:29 PM, Chuck Guzis wrote:
On 01/26/2017 06:01 PM, Paul Koning wrote:
That's a good point. Can it really be true
that a tape error that
creates a false EOT results in the loss of all remaining data?
Surely the designers weren't *that* stupid?
It happens. You can't skip over it or even space to EOT and then read
backwards. Some "intelligent" drives were really stupid.
--Chuck
8:29 a.m.
On Thu, Jan 26, 2017 at 09:01:21PM -0500, Paul Koning wrote:
It could with drives with built in compression.
--
- db at FreeBSD.org db at db.net http://www.db.net/~db
On Jan 26, 2017, at 1:23 PM, Maciej W. Rozycki
<macro at linux-mips.org> wrote:
On Wed, 25 Jan 2017, Nico de Jong wrote:
That's a good point. Can it really be true that a tape error that creates a false
EOT results in the loss of all remaining data? Surely the designers weren't *that*
stupid? I did some research, and the most reasonable
outcome was that it was not
possible by normal means, because some algorithm reading synchronisation
data couldnt find out what was happening, so, the backup was ruined.....
Odd. This would imply you couldn't wind a tape past a medium error and
read what's behind, but I surely did it a couple of times with DDS tapes. 
25 Jan
25 Jan
8:31 p.m.
On Jan 25, 2017, at 1:24 PM, Stan Sieler <sieler at
allegro.com> wrote:
Hi,
We have a friend with a "tape" (DDS, DLT, or LTO ... don't know which yet)
to which was written a system backup. Thousands of files, with an EOF
between each file, and a double EOF + EOT at the end.
The problem:
They then accidentally overwrote the start of the tape yesterday
with about 1 KB of data, plus EOT.
?
Have you approached a commercial recovery service for a quote?
A few do tape media. Whether they quote or not may provide a data point about how
feasible it may be.
Good luck
Jerry
jsw at ieee.org
2760
days inactive
2762
days old
17 comments
14 participants
participants (14)
-
aek＠bitsavers.org -
cclist＠sydex.com -
charles.unix.pro＠gmail.com -
db＠db.net -
dkelvey＠hotmail.com -
js＠cimmeri.com -
jsw＠ieee.org -
macro＠linux-mips.org -
mhs.stein＠gmail.com -
mouse＠Rodents-Montreal.ORG -
nico＠farumdata.dk -
paulkoning＠comcast.net -
sieler＠allegro.com -
spacewar＠gmail.com