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