Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!watmath!clyde!rutgers!husc6!seismo!munnari!moncskermit!basser!uqcspe!tony
From: tony@uqcspe.UUCP
Newsgroups: comp.unix.wizards
Subject: Re: multivol piped to tar
Message-ID: <1113@uqcspe.OZ>
Date: Wed, 10-Dec-86 05:38:56 EST
Article-I.D.: uqcspe.1113
Posted: Wed Dec 10 05:38:56 1986
Date-Received: Sun, 14-Dec-86 11:02:42 EST
References: <360@prairie.UUCP> <10900001@bradley>
Reply-To: tony@uqcspe.OZ (Tony O'Hagan)
Organization: Computer Science, Queensland Uni, Australia
Lines: 26

In article <10900001@bradley> brad@bradley.UUCP writes:
>
>We too had the same problem on 2 different 3b5's.  After looking
>at the code I decided It wasn't that great.  The reason? Well the
>code has the same problem as cpio (on the 3b5's).  It seems that
>if you write a partial block on the end of the tape, the hardware
>on the tape drive has problems and doesn't put an end of tape marker
>out there.  This can make cpio backups no-good.

	When writing multivol and testing it on several floppies/tapes
I came across the same problem on some devices.  This is one reason why
multivol permits you to specify a limit on the number of blocks written
to a volume.  If an incomplete block is detected when writting at end of tape,
multivol rewrites it at the start of the next volume.  However, on our
micovax tape drive the last (incomplete) block appears complete and when
re-reading the volume it is missing.  Also some floppies I tested pretend to
sucessfully write past the last possible block and similarly require
a block limit.

	Tony O'Hagan
==============================================================================
Tony O'Hagan		Australia: (07) 3774125  International: +61 7 3774125
University of Queensland	CSNET:	tony@uqcspe.oz	ACSnet:	tony@uqcspe.oz
Dept. of Computer Science	UUCP:	...!seismo!munnari!uqcspe.oz!tony
St. Lucia, Brisbane, 		ARPA:	tony%uqcspe.oz@seismo.css.gov
AUSTRALIA  4067	 		JANET:	uqcspe.oz!tony@ukc