Tape Imaging

[jim stephens]

On 8/11/2016 6:43 PM, Chuck Guzis wrote:
> On 08/11/2016 02:08 PM, Stan Sieler wrote:
>
> <snip>
> I've had a couple of tapes with "fooler" double file marks.  The first
> was a zero-length file--had I thought to look at the block count
> (000000) in the HDR label, it would have been obvious.
>
> The second was a bit more involved--the tape started off in 6250 GCR
> mode and read to EOF just fine.  However, I picked up perhaps half a MB
> of data, which seemed too little for a 10" reel.  Rewind, manually set
> the density to 1600 and read, letting the drive skip over what was now
> interpreted as erased tape.  What followed was a complete half-reel of
> 1600 data that would have been lost.  My guess is that someone had an
> "oh sh*t" moment, reset the density manually and finished the tape off
> in the lower density as intended.
That sounds like someone just set a Cipher 990 or such to 6240 GCR and 
overwrote it.  The 1600bpi was residue which was previous tape contents?

Sometimes the stars align and there are not any tape errors when you do 
what you do.  Only way to know is whether there is a PE burst at the 
start of the 1600bpi data, which would be there if they had done what 
you suggest.  And PE bursts should only appear @ the BOT I think as you 
say with streamers.

I don't know what the rack Pertec PE formatters did.  Those were the 4" 
high boxes with a couple of boards with the original twin 50 pin input 
IDC connectors on the back, and cabling out to the tape, which was a 
Pertec of some sort.

I also had a 6" 600' only Pertec formatted, with a builtin PE 
formatter.  I don't know if either wrote the PE Burst.

That was mainly useful on the Cipher 1600 / 3200 drives to figure out 
the density on read.  (I think).
thanks
Jim
>    I don't know if this could be
> recovered with most SCSI streamers, which don't allow density changes
> except at BOT.
>
> War stories...I love 'em.
>
> --Chuck
>
>
>
>
>
>
>
>
>
>
>> (Yes, that begs the question...if you're archiving a tar tape ... do
>> you *want* the data past the first EOF?  (Which could be part of a
>> prior (and longer) tar, or something else.))  (And then there are the
>> people who put tar after tar after tar on the same tape :)
>>
>> Stan
>>
>