Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/18/84; site smeagol.UUCP
Path: utzoo!linus!decvax!ittatc!dcdwest!sdcsvax!sdcrdcf!oberon!smeagol!earle
From: earle@smeagol.UUCP (Greg Earle)
Newsgroups: net.unix-wizards
Subject: Tar(1) portability???
Message-ID: <535@smeagol.UUCP>
Date: Mon, 6-Jan-86 16:07:19 EST
Article-I.D.: smeagol.535
Posted: Mon Jan  6 16:07:19 1986
Date-Received: Wed, 8-Jan-86 20:10:24 EST
Distribution: net
Organization: Spacecraft Data Systems, JPL, Pasadena, CA
Lines: 32

I just had my first experience with 4.2BSD <-> System V tar (un)portability,
which I would like to relate.
I was developing an xmodem program on my Sun, for use on a Perkin-Elmer 3200
series computer, running XELOS (System V).  I used 
	tar cvbf 20 /dev/nrmt0 <file>
on the Sun side (on a CDC 9 track), and then mt eof 2 to write end-of-tape.
When I took it down to the Perkin-Elmer site, an attempt to 
	tar tvbf 20 /dev/rmt/0m
yielded back-and-forth motions on the tape drive (an older Cipher model),
and a 'tar: read error' from tar.  I took two different tapes down, with the
same result.  Nothing would make it read the tape.  This site also has an
AT&T 3b5, which uses the identical CDC 9-track as the Sun, so I tried to
read it on that.  In this case, 'tar tvbf 20 /dev/rmt/0m' at least was able
to access the tape, but instead of the single file entry for the tar
directory, it started replicating this file entry ad nauseum/infinitum.  I
had to kill the tar to stop it.  I then did a 'tar xv' to extract, and was
hopeful when it finished properly, and the output file size matched the
tar directory entry size.  Unfortunately, when I looked at the file, what
really happened was that it took a chunk of one of the functions, and it
replicated that over and over until it filled the proper file size.  Note:
I also got a 'tar: Blocksize = 2' on the extract, which I thought had
something to do with a BSD filesize, but I thought tar was independant of things
like that!  To make things more interesting, I tried an 'od -c < /dev/rmt/0m'
and got the header and the (real) beginning of the file, but od decided that
the file ended after 2 blocks (2Kbytes).

Anyone have any similar experiences, or know what is going on??

	Greg Earle
	JPL
	sdcrdcf!smeagol!earle (UUCP)
	ia-sun2!smeagol!earle@cit-vax.arpa (ARPA)