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