Tape dumping, Rays epiphany

To Wit (about dd blocking handling) The original need for dd came with the 1/2" tapes used to exchange data with other systems and boot and install Unix on the PDP/11. Those days are gone, but the 9-track format lives. To access the venerable 9-track, 1/2" tape, dd is superior. With modern SCSI tape devices, blocking and unblocking are no longer a necessity, as the hardware reads and writes 512-byte data blocks. ( what i was familiar with ) However, the 9-track 1/2" tape format allows for variable length blocking and can be impossible to read with the cp command. The dd command allows for the exact specification of input and output block sizes, [[and can even read variable length block sizes, by specifying an input buffer size larger than any of the blocks on the tape.]] (Stan was right on target here eh ?) Short blocks are read, and dd happily copies those to the output file without complaint, simply reporting on the number of complete and short blocks encountered. Murphy's Law was postulated long before digital computers, but it seems it was specifically targeted for them. When you need to read a floppy or tape, it is the only copy in the universe and you have a deadline past due, that is when you will have a bad spot on the magnetic media, and your data will be unreadable. To the rescue comes dd, which can read all the good data around the bad spot and continue after the error is encountered. Sometimes this is all that is needed to recover the important data. Example dd bs=265b conv=noerror if=/dev/st0 of=/tmp/bad.tape.image Yup .. using cat to do the same thing, it gets the err signal and drops, but dd can be told to ignore it So in this case its clearly superior, and the *only* tool for 9 track tapes, ( due to the block handling ) So i stand before you better educated. thx to those that filled in the missing bits Raymond