Original message at end. Thanks to all who responded:
Dennis Martens <MARTENSD@health.qld.gov.au>
Baranyai Pal <bp@hszk.bme.hu>
JOSEPH AAJ Chackompally <AAJ@necsin.nec.com.sg>
Rich Kulawiec <rsk@gsp.org>
Brian Sherwood <sherwood@alux4.micro.lucent.com>
Dennis and Baranyai suggested variants on the actual (and simplest)
solution (which also occurred to me as I was driving home last night):
rsh other.host "dd if=/dev/rmt0 bs=5120" | cpio -iB
They suggested that "conv=swap" or "conv=notrunc,noerror" might need to
be applied to the dd command. The above worked without those options.
Baranyai and Brian also suggested obtaining GNU cpio. A fine idea, but
the above solution was simpler.
Rich sent along a little C program to read a tape; I include it here with
his comments for those interested in exploring this problem further at a
lower level ...
All done. Thanks (once again) for helping me to be a hero, folks!
> I hesitate to send this because (a) it may not solve your problem
> and (b) it's exceedingly ugly code from a long, long time ago. My excuse
> is that it was a very quick hack to read cpio tapes from BTL which were
> written with -c turned on -- it was never intended to be run more than
> once or twice. However, this little program (rcpioV.c) may solve your
> problem...once you stop laughing at the code. It reads stdin and takes
> *no* arguments: it just extracts what it finds.
>
> I figure that it's probably worth the 60 seconds that it'll take to compile
> it and try it. (It *does* compile under SunOS 4.1.4, at least.)
>
> #include <stdio.h>
> #include <sys/file.h>
>
> /* Attempt to read Btl Cpio (Sys V) format with -c turned on */
> /* rsk 12/14/83 */
>
> struct bozo {
> int h_magic; /* 070707 */
> int h_dev;
> int h_ino;
> int h_mode;
> int h_uid;
> int h_gid;
> int h_nlink;
> int h_rdev;
> long h_Longtime; /* Same as h_mtime */
> int h_namesize; /* length of h_name inc. null byte */
> long h_Longfile; /* Same as h_filesize; 0 -> dir */
> char h_name[255]; /* Null terminated */
> } Hdr;
>
> char header[500];
>
> main() /* Use stdin 'cause I'm lazy */
> {
> int c,i;
> FILE *fd;
> long bytes;
> for(;;) {
> for(i=0;i<500;i++)
> header[i] = '\0';
> i = 0;
> while( (c=getchar()) != '\0' && c != EOF) {
> header[i++] = c;
> }
> if(sscanf(header,"%6o%6o%6o%6o%6o%6o%6o%6o%11lo%6o%11lo%s",
> &Hdr.h_magic, &Hdr.h_dev, &Hdr.h_ino, &Hdr.h_mode,
> &Hdr.h_uid, &Hdr.h_gid, &Hdr.h_nlink, &Hdr.h_rdev,
> &Hdr.h_Longtime, &Hdr.h_namesize,&Hdr.h_Longfile,Hdr.h_name) == -1) {
> printf("Scanf failed\n");
> exit(1);
> }
> printf("Mode: %6o Nmsize: %8d Length: %11ld Name: %s\n",
> &Hdr.h_mode, Hdr.h_namesize, Hdr.h_Longfile,Hdr.h_name);
>
> if(Hdr.h_magic != 070707) {
> printf("Bad magic number = %o\n",Hdr.h_magic);
> exit(1);
> }
> if(Hdr.h_Longfile == 0l) {
> mkdir(Hdr.h_name,Hdr.h_mode);
> }
> else {
> if( (fd=fopen(Hdr.h_name,"w")) == NULL) {
> printf("Open failed on %s\n",Hdr.h_name);
> exit(1);
> }
> bytes = Hdr.h_Longfile;
> while( (bytes--) != 0l) {
> c=getchar();
> putc(c,fd);
> }
> if(fclose(fd) == -1) {
> printf("Close failed on %s\n",Hdr.h_name);
> exit(1);
> }
> }
> }
> }
Original message ..
>
> Searched about half of the archives at latech.edu, no hits.
>
> One of our customers has shown up with a DDS-1 tape created on a Sun box
> with 'cpio -ovBcdum "*.stuff"' >/whatever. We haven't been able extract the
> archives (though 'dd' confirms that the data is on the tapes).
>
> None of our Suns has a DDS drive installed. The DDS drives on our other
> Unix systems (HP-UX 9 & 10, AIX 3 & 4, Digital Unix 3 & 4, Data General,
> SCO) report read errors or 'out of sync'. -R did not re-sync
> successfully on HP-UX, and the usual block_sizes failed on AIX.
>
> I think I've seen this problem before .. I believe the issue is that the
> header produced with -c on Solaris has portability issues, and that the
> better method is to use '-H odc' when generating the tape. I'd prefer to
> avoid asking the customer to re-gen his tape however, and would like to
> avoid swapping drives around, if possible.
>
> Does anyone have a method that works on any of the above referenced
> *nixes to work around this problem?
>
> Will summarize.
>
This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:12:36 CDT