Problems reading or writing tar tapes
Previous |
Next
I know there’s data on my tape, but tar acts like it’s blank.
There are two possibilities. If it’s a DAT tape you wrote yourself on this same machine, (or if you can recreate the problem using a tape you create yourself), it’s likely your drive has a firmware bug in its variable block support. (Variable block i/o allows tar to read a tape without knowing what blocksize was used to write the tape.) The workaround is to read the tape using the -V option to tell tar not to use variable block i/o. If the tape wasn’t written with a standard blocksize, it may take a while longer for tar to figure out what blocksize was used (without variable blocksize support, it has to try all the possibilities), but at least it will work.
The second possibility is that the tape was written with hardware compression turned on, but your drive doesn’t support compression. You can find out if your drive supports compression using the mt status command. There isn’t any workaround for reading a tape written with compression on a drive that doesn’t support it; you’ll have to rewrite the tape .
When I read or write a tape, what does it mean if some of the files are listed in yellow?
It means those appear to be ASCII text files and that tar has tried to convert the line endings between the PC convention of a CarriageReturn-LineFeed combination at the end of each line and the UNIX convention of just a single LineFeed character. (The assumption is that since the tar format is basically a UNIX standard, files in a tar archive should follow the UNIX convention but be stored in the PC convention on your hard disk.)
You can suppress this automatic conversion by using tar -r.
I can read the tapes I create, but they can’t read them on their machine.
There are a couple possibilities. One is that you’ve written the tape in the wrong bytesex for the other machine and the other is that you’ve written the tape using compression and that the drive on the other machine doesn’t support compression.
By default tar creates tapes in little-endian format, meaning that when it writes a 16-bit binary number on the tape, it writes the byte with the least significant byes (the little end) first. Some UNIX or Linux workstations follow the opposite convention. The solution is to write tapes in big-endian format using tar -bB. But if that’s not convenient, the workaround on the UNIX machine is to read the tape using the following command line, where tapedevice refers to the name of tape unit on that UNIX machine:
dd conv=swab < /dev/tapedevice | tar xf -Tar complains about “garbled headers.”
There are two possibilities. One is that your tape has a bad spot. The other is that your archive isn’t really a tar archive at all.
When reading an archive, tar expects the data to fit a standard layout defined by the POSIX standard. Each file in the archive is expected to be preceded by a 512-byte header telling the filename, the timestamp, etc. Each header has a checksum so tar can verify the data really is good. If it encounters a header that doesn’t fit the standard, tar assumes it has it a bad spot in the archive. But rather than just give up, tar scans down through the rest of the archive, byte-by-byte, looking for a new header that actually is valid.
Tapes do occasionally develop bad spots, and this ability to scan forward can be invaluable in retrieving data that otherwise would be completely lost. But if the data really isn’t a tar file at all, then scanning ahead is not going to achieve anything.
Why can’t I read or write a tape under Windows 9x?
Windows 9x doesn’t support the tape backup API used by tar. As a consequence, tar has no way of talking to the tape drive under Windows 9x. The only solution, if you need tape support, is to upgrade from Windows 9x to Windows NT/2000/XP/Server.
When I try to read a tar tape, tar says it was written with a different blocksize or that the blocksize is larger than my hardware can support.
Very likely, you’re trying to read a DAT tape created on a Silicon Graphics machine. A lot of SGI machines were set up to write tapes with a default blocksize of 256K. That’s much larger than most PC’s can support. Most PC’s will only support a maximum blocksize of about 64K; PC’s using a PCI bus will go to about 102K, but still far short of what SGI uses. The workaround is to rewrite the tape on the SGI using a more reasonable blocksize. You can do this using the UNIX tar b option to specify a smaller “blocking factor.” (You multiply the UNIX blocking factor by 512 to get the number of bytes/block.) A good choice is a blocking factor of 20, meaning a 10,240-byte blocksize, which corresponds to the POSIX standard for tar tapes. The complete command line on the SGI will look something like this:
tar cvb 20 files-to-be-added-to-the-tapePrevious | Next
Hamilton C shell, as it first wakes up.
A first few commands.
You can set the screen colors to your taste.
