DLT IV DLT 8000 40GB Compressed file how to read using dd

[Richard John Dixon]

I have received 10 DLT IV tapes and using my DLT8000 drive I can correctly read the 3.5 GB file enclosed by overriding the settings to be 40GB uncompressed in 9 cases. The 10th case (the most important file which we wish to load to our software) when I use the tape overide to set it at 40GB uncompressed it reverts to 40GB compressed when the dd command is used.
The resultant file is 2.9GB in size and is corrupted (or compressed) and cannot be read by our software. I have tried putting a c after the device name to no use. Is there a unix command I can use to force the tape to be read at 40GB uncompressed or a way of uncompressing the resultant 2.9GB file so it retains its correct 3.5GB size.
Hope to hear from someone who is wiser than myself.

Richard

[Steven E. Protter]

Shalom,

You need to know how the tape was created, most importantly what tool was used to read it.

dd might not be the right tool.

SEP

[Richard John Dixon]

I have spoken to the supplier of the ten tapes and they insist that they they were all written in the same way. The company is Western Geco part of Schlumberger if that's any help. The dd command worked for the other 9 tapes maybe the file or tape are just corrupt. What alternatives are they to reading the tape? I know it hasn't been tar'd to the tape.



Richard

[Steven Schweda]

When _reading_ a tape, you should not need to
specify the density or the compression
setting. The drive can see what it's dealing
with, and it should simply do the right
thing.

If the data it sees are compressed, then the
drive should expand them before you see them.
I know of no way (with a normal tape drive)
to access the raw compressed data on a tape
which was written with compression. (I
assume that some exotic SCSI command and/or
special drive firmware could do it, but who
cares?) I doubt that "dd" could manage it.

> The resultant file is 2.9GB in size and is
> corrupted [...]

Did you get any errors when you read this
tape? Perhaps bad data were written onto the
tape. You might ask the source how big the
file was supposed to be, and/or get a
checksum for it, which you can use to check
its integrity.

Curiosity: Why ten tapes for files which
should have fit onto one tape?

Aside: And some people wonder why there's
still a market for VMS, where BACKUP's
built-in data integrity features remove the
mystery of where to assign blame in cases
like this, if nothing else.

[Bill Hassell]

As mentioned, the compression and density on a tape cannot be overridden because the tape drive does all the work. The device file settings for data only have an effect for writing, never for reading. You can't change the way the tape is read. You'll have to return the tape to the supplier to verify that it is indeed valid, or get a replacement tape. I know of no tape drive in the last 20 years that could be forced to read at a different density -- the tape drive doesn't have any code to override the coded density information.

[Richard John Dixon]

Thanks to everybody who responded. The tape or file on it must have been corrupt and I have now received the correct file on a DVD, which has been loaded. I did request all the files to be put on a single DLT but you don't always get what you want.

Thanks again

[Richard John Dixon]

Thread now closed