2 May
2002
2 May
'02
10:51 a.m.
At the portion of the work where you just want to get
the stuff
spooled to a file, you dont care about "block size" yet, you
just need to get it pulled off.
Unix will treat any device as a stream of bytes
And therein lies the problem.
...
Do you see what im getting at here ? hello ?
No, I don't, because your entire example was disk-centric,
which simply doesn't apply to tapes. Tell you what... how
about an empirical test?
Go buy a 9-track drive and hang it on your *nix box.
Let me send you a 9-track tape. You read it any way
you want. You send me the tape back.
Then you go get a second tape, and put the data back on
any way you want. Then send it to me, and I'll tell you
if your technique works or not.
You game?
-dq
2 May
2 May
11:27 a.m.
On Thursday 02 May 2002 14:51, you wrote:
You would rather work the drive to death ?
You know, any really old tape you are attempting to recover
you really do not want to be running it thru the tape deck
very much
disks are huge these days, and the content is best messaged
on a new disk rather than an old tape.
Wrong i used it as an example, the raw stream already fit
its intended destination in the hard drive case.
spools off a cdrom in the wanted configuration in the cdrom
case, and best fiddled with on disk in the old-tape case.
At the portion
of the work where you just want to get the stuff
spooled to a file, you dont care about "block size" yet, you
just need to get it pulled off.
Unix will treat any device as a stream of bytes
And therein lies the problem. Do you see
what im getting at here ? hello ?
No, I don't, because your entire example was disk-centric, which simply doesn't apply to tapes.
Yes it does
Tell you what... how about an empirical test?
Well since we already know the behavior, we already know
the results dont we ?
Go buy a 9-track drive and hang it on your *nix box.
Let me send you a 9-track tape. You read it any way
you want. You send me the tape back.
Then you go get a second tape, and put the data back
on
any way you want. Then send it to me, and I'll tell you
if your technique works or not.
this is very predicatble if you know the raw behavior
of the devices isnt it
the whole idea was to point out some of this raw behavior
Raymond
12:16 p.m.
As one example, consider the case of undelimited tape records
where the \n is only implied. They were sometimes called
'Card-image' but were in use long after cards.
And let's all try to cut down on list squabbling, please.
John A.
- - - -
No, I don't, because your entire example was
disk-centric,
Wrong i used it as an example, the raw stream already fit
its intended destination in the hard drive case.
spools off a cdrom in the wanted configuration in the cdrom
case, and best fiddled with on disk in the old-tape case.
which simply doesn't apply to tapes.
Yes it does
1:06 p.m.
Re:
You would rather work the drive to death ?
You know, any really old tape you are attempting to recover
you really do not want to be running it thru the tape deck
very much
disks are huge these days, and the content is best messaged
on a new disk rather than an old tape.
Absolutely! Very good point.
However, if I notice recovered-reads (or hard errors) on old 9-track
tapes, I often see fewer recovered reads (or hard errors) if I try
the tape one more time. I assume that going over the heads once
may have knocked off a bit of dust/dirt/something that affected
the tape the first time. Note that I don't discard the
results of the first run until the second run finishes...
I've had one tape break during a second run :)
BTW, the only way you can be *SURE* you got all the data on
the tape is if *EVERY* read-request returned fewer characters
than you asked for. E.g., if you did:
bytesread = read(fromfd, buffer, BUFSIZE);
and you get BUFSIZE bytes in, then there's a chance that that
tape record had BUFSIZE + 100 bytes ... and you've just lost
those last 100 bytes.
Sure, sure ... it's not a major problem if you know the tape
format ahead of time. (E.g., MPE V tapes can't have records
more than 64 KB, and the actual limit is somewhat less than that.)
But the point applies to unknown tapes.
Stan Sieler sieler(a)allegro.com
www.allegro.com/sieler/wanted/index.html www.allegro.com/sieler
Unix will treat any device as a stream of bytes
And therein lies the problem. Go buy a
9-track drive and hang it on your *nix box.
Let me send you a 9-track tape. You read it any way
you want. You send me the tape back.
> Then you go get a second tape, and put the data back on
> any way you want. Then send it to me, and I'll tell you
> if your technique works or not.
8123
days inactive
8123
days old
3 comments
4 participants
participants (4)
-
allain＠panix.com -
dquebbeman＠acm.org -
rmoyers＠nop.org -
sieler＠allegro.com