Let's develop an open-source media archive standard

From: Steve Thatcher <melamy_at_earthlink.net>
Date: Thu Aug 12 15:11:14 2004

comments below...

best regards, Steve Thatcher

-----Original Message-----
From: "Dwight K. Elvey" <dwight.elvey_at_amd.com>
Sent: Aug 12, 2004 3:09 PM
To: cctalk_at_classiccmp.org
Subject: RE: Let's develop an open-source media archive standard

>From: "melamy_at_earthlink.net" <melamy_at_earthlink.net>
>
---snip---
>
>The image file that you are discussing is only good as a "how to" to write
>arbitrary data to arbitrary media. It is only good for creating a final
>media image because the format being contemplated (mixing data into the
>physical spec) will preclude the file from standing on its own.

No, that is not true. The description of the physical data in the archive
should be sufficient to recover the system side data. I can state
this because the system side data is just a subset of the physical
data.

*** if all you are describing is tracks, sectors and heads then you have not included ANY information as to how to get at a specific piece of data in the image file. You can certainly get a sector piece but you will have no clue how to connect individual pieces together to make a block of data. Only platform specific information will get you to that point and that means text has to be included to tell someone how to write software that accesses a particular file structure on a particular OS. If you have that file information when the image file is created, it would be easy to save the info and then be able to get at any file inside of the image file without ANY knowledge of the physical file structure or OS.

 I recommend that the archive should include enough information to
translate from the physical to the system but for archiving purposes,
that is not absolutely necessary.

*** this information is not trivial, but if we make the data separate then it is if we save the file information too.

 It is not that hard to describe as
part of the header what FM looks like. Still, if we restrict all archived
information to include this, some unknown formats may not be archived
because the person with the data doesn't know that format. It is
better to capture the data first.
 It may also be that the only way that person has to capture the
data is the output of a controller chip. The archiving should allow
this as well ( more in the format the Steve would like it all to
be in ).

*** not sure why this relates to the format I was proposing. What I was desdcribing was a way to do both low level bytes as well as blocks of data

 This file could later be combined with the more physical
information when that was available, just as a archive file that
originally had only physical information could be appended with the
data as seen by the system.
 What this means is that some of the archived files may not be directly
useable by Steve and his tools without some more in depth knowledge
about the encoding use. It doesn't make it impossible to use, just
difficult.

*** is is not a encoding issue with regards to the hardware level. There are three standards just for 8" disks - FM, MFM, and M2M. ISIS DD uses M2M and I for one want to be able to use my ISIS software independent of the media it is on. I also don't want to have to write a major utility (in other words a small OS) just to read the image file.

Dwight

>I was
>proposing identifying data blocks as files if that is what they were. The
>data blocks would have been sequential and trivial to retrieve. That is
>hardly what I would call defining a file system as part of the image file.
>
>best regards, Steve Thatcher
>
Received on Thu Aug 12 2004 - 15:11:14 BST