scs@adam.pika.mit.edu (Steve Summit) (05/23/89)
In article <184@larry.sal.wisc.edu> jwp@larry.sal.wisc.edu (Jeffrey W Percival) writes: >I have a 6250BPI reel-to-reel tape made by the VMS backup program. VMS >folks call it a "saveset" tape. I can't seem to copy this tape onto a >TK50 with Ultrix. dd appears to do the job, but when the resulting tape >is subjected to the uunet-archive program "vmsbackup", it says "end of >tape" right away. A backup saveset is not one tape file, but three (or so [1]). Tapes written by backup are ANSI-labeled tapes, including file headers and trailers. Each save set ends up as one labeled "file" on the tape (but note that a "labeled file" is implemented as more than one tape-mark-delimited tape file -- ignore this distraction if you're not interested in ANSI labeled tape formats.) A typical save set might look like file recsize nrecs what 1 80 3 [2] header 2 8192 [3] * contents 3 80 2 trailer The "contents" are the actual backed-up information, including extensive internal structure recording file types, ownership, file times, redundancy groups, etc. [4]. The best way to copy backup savesets on a Unix system is to use one of several copytape programs [5] that are able to preserve arbitrary record sizes and tape marks (i.e. multiple tape files). You can do it "by hand" using no-rewind tapes and/or the mt command: dd if=/dev/nrmt0 of=/dev/nrmt1 [6] dd if=/dev/nrmt0 of=/dev/nrmt1 bs=8192 dd if=/dev/rmt0 of=/dev/rmt1 Beware, though, that backup's default record- and block-sizes may well be different for 9-track magtape and TK50's, so the TK50 you create by such maneuvers may not be identical to one created by using backup itself to write directly to a TK50. Whether such a media-transferred saveset can be successfully read by a backup- format reading program depends of course on the robustness of the reading program. Unix is very device-independent and a program can barely tell if it's talking to a magtape or a TK50, so I wouldn't expect a Unix backup program to have any difficulty. True VMS backup might complain, although it shouldn't reject the tape outright. Steve Summit scs@adam.pika.mit.edu Notes: 1. When there are multiple savesets on the tape, the header and trailer records are, as I recall, coalesced, so that a tape with two savesets on it might look like file recsize nrecs what 1 80 3 header 2 8192 * contents #1 3 80 4 trailer/header 4 8192 * contents #2 5 80 2 trailer 2. Later versions of VMS backup write a more elaborate header file with more records. 3. Don't treat the number 8192 as gospel; my memory on this is imperfect. It may be a backup command-line parameter. 4. This internal structure used to be documented as an appendix to the backup section in the VMS utilities manual. In the new, revised VMS documentation, with a standalone manual for the backup utility, this information may no longer be documented. 5. Several have been posted and are probably available from the source newsgroups or their archives. I've written one, but it's not handy; mail me if you'd like a copy. 6. No explicit block size is specified for the copying of the header and trailer files because versions of dd I'm familiar with correctly preserve record sizes as long as they're less than or equal than dd's blocksize, which is by default 512. You could use bs=80 for the headers and trailers if necessary or to be self-documenting.
jwp@larry.sal.wisc.edu (Jeffrey W Percival) (05/23/89)
In article <11593@bloom-beacon.MIT.EDU> scs@adam.pika.mit.edu (Steve Summit) writes: >In article <184@larry.sal.wisc.edu> jwp@larry.sal.wisc.edu (Jeffrey W Percival) writes: >> (a detailed description of VMS backup tapes) Thanks for the good description. I knew about the multi-file format, and have some more info on this problem: when vmsbackup tries to read the first 8192-byte record from file 2, read(2) returns a zero. The record is on the tape, because dd can retrieve it. What could cause read(2) to return zero on a record that dd can find on the tape? Could this be related to the TK50 whirring back and forth after just having read the file mark? -- Jeff Percival (jwp@larry.sal.wisc.edu)