From: "melamy(a)earthlink.net"
<melamy(a)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.
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. 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 ). 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.
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