On Thu, 12 Aug 2004, Steve Thatcher wrote:
> 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.
As long as the original platform and OS are included in the meta data,
which should be a requirement, then the person using the archive can read
up on how files were stored on that OS and parse the data correctly. It's
extra work, but again, it is not always the case that everything will be
stored as "files" or "data objects" on the original medium. In some
cases, you can't know, or it might be too much work to find out, just what
the data objects are. What if the only way to use an imagefile is in it's
native image format or structure? I think you are discounting too many
non obvious possibilities and focusing only on your idea of the data being
represented as objects. It just isn't a universally applicable concept.
> 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.
Again, the file information *is* saved. It's in the image! It just
requires a little bit more work to get at it. Or not. It depends on if
the tools are there to do the job. My guess is after a few years, there
will be plenty of robust tools out there to extract files from all sorts
of images.
But the main point, again, is that people should not be forced to archive
everything as a data object. Remember, the whole premise of this spec was
to image data media. Everything we have discussed since then are useful
enhancements, but the basic spec, as I see it, remains the same.
> *** 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.
Then you can choose to create archive images using the spec that suit your
purposes. But don't always count on everyone else to choose your method.
You seem to want everyone to agree that your way of thinking is the only
way or the best way. It's not. That's why the spec will allow for
multiple ways of imaging media, but only out of necessity dictated by the
reality of the various forms of data storage that are out there, and not
to make everyone feel good about themselves.
--
Sellam Ismail Vintage Computer Festival
------------------------------------------------------------------------------
International Man of Intrigue and Danger http://www.vintage.org
[ Old computing resources for business || Buy/Sell/Trade Vintage Computers ]
[ and academia at www.VintageTech.com || at http://marketplace.vintage.org ]
Received on Thu Aug 12 2004 - 18:01:06 BST