On Tue, Apr 12, 2005 at 04:15:51PM +0200, Paul Bijnens wrote:
> Most modern tapedevices are not random access.
> I don't know how to "rewind a little", and neither does the gnutar
> programmer which states in the beginning of the "update.c" source
> file: "... if [the files] are on raw tape or something like that,
> it will probably lose... */ ".
That was probably me, lo those many years ago.
> I guess that if you "dd" the first file, you find a nice tar file,
> and if you "dd" the next file, which seems to be written to
> tape too, you'll find another file beginning with the last block
> again, now having the trailer replaced with the next archive members.
> Useless actually.
The fact that tar didn't give you an error is clearly a bug. You
should report it. Tar should have noticed that it's attempt to
backspace the archive failed.
It is theoretically possible to make this work on a theoretical tape
drive, if the drive in question supports the MTBSR command in the
MTIOCTOP ioctl. Back when I was working on Gnu Tar, I considered
attempting to use said command to backspace a tape drive when
attempting to append to an archive on a tape. Unfortunatly, if I
wrote such a thing, someone would eventually attempt to use it on
hardware that was incapable of doing what they wanted, and would
become very irate when their real-world tape drive behaved like a
mechanical device and destroyed their data.
Back when I was working on Gnu Tar, I had access to two different
kinds of tape drives: 9-track reel-to-reel tapes, and cartridge
"streaming" tapes. The 9-track drives a capable of backspacing a
single record (aka "tape blocks"), but reading a tape block,
backspacing, and attempting to write over the tape block will cause
the new tape block to be written to a slightly different physical
location on the tape. Eventually (how soon depends on the inaccuracy
of the paticular tape drive) the new tape block will be written on top
of the previous tape block, destroying the data on that section of the
tape.
streaming tape drives are (were) incapable of backspacing a single
record, so there is simply no way to append to a tape file.
Tape drives that use timing tracks for aligning data on the tape may
be capable of backspacing a tape block and rewriting it safely, but I
didn't have any such devices, so they were strictly theoretical.
In any case, tar has no way to tell what kind of tape drive the
archive is on, and relying on the user to know the capabilities of
their tape drive is foolish. So tar doesn't even try.
Here's how to append files to a tape archive:
1: free up a chunk of disk space on the machine with the tape drive
that is at least as large as the capacity of the tape.
2: wind the tape to the start of the archive you wish to append to ("mt
rewind" or "mt fsf N" as appropriate)
3: use dd to copy the tape archive into the free disk space ("dd
bs={size of tape blocks} < /dev/ntape > /free/space/path/tmp.tar")
4: append the files you want to the temporary copy of the tape archive
("tar rvbf {size of tape blocks} /free/space/path/tmp.tar ...")
5: backspace the tape to the start of the archive you want to append
to ("mt bsf 1" or "mt rewind", etc.)
5: Copy the new archive back to the tape with dd
("dd bs={size of tape blocks} < /free/space/path/tmp.tar >
/dev/ntape" )
Note that some tape drives will only allow you to either append to the
tape or start writing at the beginning, in which case you will have to
copy off any tape archives before the one you wish to append to, and
rewrite the tape from the beginning.
-- JF
|
