Er, no. The blocks aren't necessarily of equal size. Unix people who are used to tar often seem to have this mindset, but the general case is that records can be of varying size. DON'T DO THAT. If you use dd, you're throwing away information. Specifically, you're throwing away knowledge of the block size. Most of the conventional unix utilities don't care. Many other things do. In many cases, it's difficult or impossible to reconstruct the block sizes There are file formats for containing tape image data. The most common one is probably the simh .tap format. These all preserve block lengths, tape marks, indications of errors in reading the original, etc. Many fail to provide a means to embed metadata, but you can put that in separate adjacent files. Generally speaking, do a read of a blocksize as large or larger than the max on the tape, and the system will hand you the full record, and the actual number of bytes read. If you're writing C or scripting code, the unix read() call does this. From the command line, you can do it with dd - specify a large block size and a count of 1, and it'll tell you what it actually got as it exits. For 9 track, few systems could write blocks larger than 32k or 64k, so those are decent guesses for "large" there. If it's DLT or something more modern, then the largest possible block might be a lot larger. The system reading the tape may impose a limit based on available buffer space. You should able to iteratively determine the largest size it will accept. Many of the quarter-inch cartridge formats actually don't support block sizes other than 512 bytes. If they were used on systems that expected to be able to write larger and/or variable records, the system hardware or software may have implemented a logical blocking layer on top of the 512 hardware layer. If you're reading one of these and don't have the original hardware/software to decode it, you'll have to figure out how to decipher it yourself. De

shadoooo via cctalk wrote: I've sometimes created my own simh .tap to Boottape converter (an later found out that such a thing exists on the net) to create some boottapes for my pdp11's using a tandberg 8GB quarter inch drive. It worked (on Freebsd). I've installed 2.11BSD and on a KA630 Quasijarus Unix, If you set the blocksize to variable you get back the read byte count the new copied tape (that's what the .tap formats are made for). I know it is the other way around (.tap->tape) but this is my old q&d tape write program, you hae made the other half yourselves... #include<stdio.h> #include<stdlib.h> #include<string.h> #include<sys/types.h> #include<sys/ioctl.h> #include<sys/mtio.h> #include<fcntl.h> #define MAXBLOCK 50 extern int errno; main() { FILE * ifp; FILE * ofp; unsigned char buf[MAXBLOCK*512]; unsigned char * bufp; unsigned long foffs=0; struct mtop mtio; int blnum,mark,mt; unsigned int blen, tlen; mark=0; if((ifp=fopen("tapefile","r"))==NULL) { fprintf(stderr,"Cant open input file\n"); exit(-1); } if(system("mt -f /dev/sa0 blocksize 0")<0) { fprintf(stderr,"Can't set variable blocksize on /dev/sa0\n"); exit(-1); } if((mt=open("/dev/sa0", O_CREAT|O_TRUNC|O_WRONLY,0666))<0) { fprintf(stderr,"Can't open tape device\n"); exit(-1); } blnum=0; l0: while(1) { if(fread(&blen, sizeof(uint32_t),1,ifp)!=1) { fprintf(stderr,"Can't read blocklen\n"); fclose(ifp); close(mt); exit(-1); } foffs+=sizeof(uint32_t); if(blen==0) { if(mark) { fprintf(stderr,"EOT detected\n"); fclose(ifp); mtio.mt_op = MTWEOF; mtio.mt_count = 2; if (ioctl(mt, MTIOCTOP, &mtio) < 0) fprintf(stderr, "MTIOCTOP err: %d\n", errno); close(mt); exit(0); foffs+=sizeof(uint32_t); if(blen==0) { if(mark) { fprintf(stderr,"EOT detected\n"); fclose(ifp); mtio.mt_op = MTWEOF; mtio.mt_count = 2; if (ioctl(mt, MTIOCTOP, &mtio) < 0) fprintf(stderr, "MTIOCTOP err: %d\n", errno); close(mt); exit(0); } else { fprintf(stderr,"tapemark detected foffs= %08x\n", blen,foffs); mark=1; mtio.mt_op = MTWEOF; mtio.mt_count = 1; if (ioctl(mt, MTIOCTOP, &mtio) < 0) fprintf(stderr, "MTIOCTOP err: %d\n", errno); goto l0; } } else mark=0; fprintf(stderr,"foffs %08x, blen bl %d = %d:%04x\n",foffs,blnum,blen,blen); blnum++; blen=blen&0x0fffffff; // erase error flags if(fread(buf,sizeof(unsigned char),blen,ifp)!=blen) { fprintf(stderr,"Cant read blen %dbytes into buffer\n",blen); fclose(ifp); exit(-1); } if (write(mt, buf, blen) < 0) { fprintf(stderr,"Cant write blen %d bytes into buffer\n",blen ); fclose(ifp); close(mt); exit(1); } foffs+=blen; if(fread(&tlen, sizeof(uint32_t),1,ifp)!=1) { fprintf(stderr,"Cant read trailing blocklen\n"); fclose(ifp); exit(-1); } foffs+=sizeof(uint32_t); if(blen!=tlen) { fprintf(stderr,"heading blocklen %08x != trailing blocklen %08x\n", blen,tlen); fclose(ifp); exit(-1); } bzero(buf,MAXBLOCK*512); } } Regards to Italy, Holm -- Technik Service u. Handel Tiffe, www.tsht.de, Holm Tiffe, Goethestrasse 15, 09569 Oederran, USt-Id: DE253710583 info at tsht.de Fax +49 37292 709779 Tel +49 37292 709778 Mobil: 0172 8790 741

On 09/17/2020 12:29 AM, shadoooo via cctalk wrote: This is not necessarily true. Many systems can handle "VBS" (Variable Block Sequential) tape files. But, yes, fixed block size is more common. OK, the tape formatter will know, and signal the system when reading. So, you would issue a read command to the OS, giving a block size at least as big as the biggest block you expected to see. The formatter/interface would report the number of bytes in that block. Now, when putting a tape image into a disk file, that gets more complicated. There are various "tape container file" schemes where the block size is encoded into the data in some form. If the tape just contains a single file, it may not matter as the data is just a stream of bytes. But, if the tape contains multiple files, then it is pretty important to preserve the record lengths and file marks. I'm a lot more familiar with IBM and DEC tape formats, and had my own container file format to process disk images of tapes. Unix systems support all these options in one way or another, but tar tapes are just a stream of bytes, and I don't think the block size has much effect. Jon