Let's develop an open-source media archive standard

From: Cini, Richard <RCini_at_congressfinancial.com>
Date: Thu Aug 12 09:33:02 2004

        How would one actually go about re-generating an original media from
the metafile? Do we contemplate connecting some future computer's I/O port
to a 34-pin ribbon cable connected to a 1980's vintage floppy drive? At some
point in this process we're going to have to make some detailed assumptions
on how the metadata will be used 50 or 100 years from now.

        Also, the metafile not only has to include information about the
"user" data areas of the disk but also the system areas (the stuff written
to the media by the controller -- address marks, gaps, sync bits, etc.).

        This would require us to not only compile the general media format
data but also data on the controller used to generate the media (chip specs,
data gleaned from examining the "format" programs used, etc.).

        The reason why I ask is that somehow we're going to have to test the
archival/restoration process to see that it works. It's like making tape
backups but never testing them with a restore.

        This might be obvious, but I've been accused of stating that before
:-)

Rich

-----Original Message-----
From: cctalk-bounces_at_classiccmp.org
[mailto:cctalk-bounces_at_classiccmp.org]On Behalf Of Steve Thatcher
Sent: Thursday, August 12, 2004 10:17 AM
To: General Discussion: On-Topic and Off-Topic Posts
Subject: RE: Let's develop an open-source media archive standard


comments embedded below...

best regards, Steve Thatcher

-----Original Message-----
From: Hans Franke <Hans.Franke_at_siemens.com>
Sent: Aug 12, 2004 10:06 AM
To: Steve Thatcher <melamy_at_earthlink.net>,
        "General Discussion: On-Topic and Off-Topic Posts"
<cctalk_at_classiccmp.org>
Subject: RE: Let's develop an open-source media archive standard

Am 11 Aug 2004 14:47 meinte Steve Thatcher:
> I realize that the idea is to create a format to make re-creation
> of media possible for a variety of platforms. We can certainly do
> that and have its only function be to maintain a physical data
> format. My added idea is that the data and the formatting be
> separated so that a simple utility on a non-target platform could
> extract data from the image file.

Well, physical format and data is not always seperable. In some
circumstances the physical format is part of the onformation an
application needs, and differs form media to media (e.g. copy
protection schemes)

*** the separated data that I am talking about is what would be accessed
through normal OS channels. Copy
protection schemes, special destroyed sectors, etc are not accessible
through the OS.

> If we create a physical description only and do not abstract
> the data then any emulator must understand the OS file
> structure in order to retrieve any internal file representation.
> My idea would make the file re-creation simple in that the xml
> image file would be parsed for the actual file data that an
> emulator would need. This makes the emulator easier.

But what if the emulator needs the physical format information?

*** I have not proposed that the physical format information be excluded...

> To retrieve a file from the physical layout that it at the end
> of this message, the emulator must know the actual disk format
> that is used on the target system (the one the image file was
> made for). I have seen cp/m systems where the actual physical
> sectors were sequential on disk and the OS file sector was
> actually virtual to increase speed. Not my idea of the way to
> do it. It is much easier to make the physical sectors slewed
> so that a physical sector is a file sector. These are the types
> of issues you will have to overcome if an emulator must totally
> understand each and every file system for a cp/m version for
> example.

At least within a CP/M system it usualy doesn't matter at all
how the files are stored on a disk. Except for some odd apps
who tried to implement system specific copy protection schemes,
all and every CP/M app accesses files just via BDOS which already
hides the real disk strukture.

*** talk to other people here and one of their arguements for keeping things
all together was being able to
access track and sector directly. As for BDOS, that is fine, but keep in
mind that BDOS was customized for nearly every cp/m platform
Received on Thu Aug 12 2004 - 09:33:02 BST