From owner-freebsd-hackers  Thu Jun 19 17:25:11 1997
Return-Path: <owner-hackers>
Received: (from root@localhost)
          by hub.freebsd.org (8.8.5/8.8.5) id RAA29227
          for hackers-outgoing; Thu, 19 Jun 1997 17:25:11 -0700 (PDT)
Received: from seagull.rtd.com (seagull.rtd.com [198.102.68.2])
          by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id RAA29222
          for <freebsd-hackers@freefall.FreeBSD.org>; Thu, 19 Jun 1997 17:25:09 -0700 (PDT)
Received: (from dgy@localhost)
	by seagull.rtd.com (8.8.5/8.8.5) id RAA11881;
	Thu, 19 Jun 1997 17:27:22 -0700 (MST)
From: Don Yuniskis <dgy@rtd.com>
Message-Id: <199706200027.RAA11881@seagull.rtd.com>
Subject: Re: Opus diskettes
In-Reply-To: <199706192024.NAA22936@phaeton.artisoft.com> from Terry Lambert at "Jun 19, 97 01:24:25 pm"
To: terry@lambert.org (Terry Lambert)
Date: Thu, 19 Jun 1997 17:27:22 -0700 (MST)
Cc: dgy@rtd.com, terry@lambert.org, freebsd-hackers@freefall.FreeBSD.org
X-Mailer: ELM [version 2.4ME+ PL31 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-hackers@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk

In the words of the world-renowned author, Terry Lambert:
> > > dd if=/dev/floppy skip=4k conv=swab of=file_without_VTOC
> > 
> > Hmmm... perhaps you meant ^^ "8" since skip expects # of blocks
> > as an argument?
> > 
> > In either case, this doesn't cut the mustard  :-(  I looked through
> > a few other OPFIL's and they *don't* appear to be compressed.  For
> > example, one contained /etc/.profile which was entirely readable.
> > 
> > Perhaps just a tape archive with some bogus crap on the front
> > end?  file(1) sees them as "data"  (BFD!)
> 
> I doubt the data is compressed as well; the statement up front
> was that the disks contained compressed data.

The first disk I examined happened to have lots of executables
on it and no real text that was obvious.

> The 4k is a VTOC (Volume Table Of Contents); it is the old-SRV3
> "disklabel" which was a non-optional result of the "format"
> command.

This doesn't appear to be the case.  I've tried stripping various amounts
off of the front of the file and it's still unrecognizable as a tarball
or a cpio archive.  (sigh)  I guess I'll have to install the d*mn
coprocessor and unpack them the hard way  :-(

> Generally, we used the disks for tar archives; however, you should
> also check for cpio archives (more likely; without the extra
> package installed, SVR3 did not have tar, only cpio, especially
> on OPUS and Fortune systems boxes).

Yes, previous OPUS release were just cpio archives
	cpio -icvtdumB ...

> Worst case, they are S51K file systems.

Or, perhaps I'll just punt and leave the man pages broken.  No one
seems to be missing it... ;-)

Thx!
--don